Re: Multi-branch modules possible?

[Paul Sander]

>--- Forwarded mail from address@hidden

>----- Original Message ----- 
>From: "Derek Robert Price" <address@hidden>


>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Dennis Jones wrote:
>>
>> >Along the lines of Andy Jones' "Tagging across branches" thread posted
>> >earlier today, I have a similar question.
>> >
>> >There have been many occasions in which I have wished it were possible to
>> >have a module where some directories were on one branch, and some
>> >directories were on another (and so on).  I know CVS does not have native
>> >support for this feature (I've heard ClearCase does however -- is that
>> >true?), but I was wondering if there were any plans to add this
>capability
>> >to CVS at some point in the future?  Has it ever been considered?
>>
>>
>> Why would you want to do that?

>Simple.  Say you have a significant number of applications that are built
>from a large directory tree, and all of the applications are co-related to a
>single product.  That is, there are dozens of applications that make up a
>released product, and they all share lots of code from many different
>directories.

>Now, suppose a branch gets created to provide a special version of just one
>particular application (or a couple of applications), and that branch must
>be maintained for a significant period of time (weeks, months, or even
>years).  If any of the shared code on the main trunk gets modified, those
>changes must be merged onto all existing branches in order for them to stay
>in sync with the main trunk.  The more branches that exist, the more chance
>there is for error, either during the merge process, or in developers
>forgetting to merge his change(s) onto all live branches.

>This might seem like a contrived example, but it is not.  I do some
>part-time development for a company that tries to maintain mutliple versions
>of their product simultaneously, and those versions are each on a separate
>branch.  However, there is LOTS of code that is shared between the versions,
>and relatively small sections that differ across versions.  When changes
>occur that should affect all versions, it is a maintenance nightmare to get
>all versions of the product up to date.  This problem is exacerbated by the
>fact that this is an international application, translated into 16 languages
>(currently, and more are planned), and any change to the UI must be
>duplicated for each locale, and for each version.

>I have made repeated efforts to talk the client into not trying to manage so
>many simultaneous versions, but there is no talking them out of the way they
>do things.  So, as their resident "expert" in CVS (and an expert I am not -- 
>but before I came along, they weren't even using revision control -- now
>just TRY to imagine this scenario without it!!!), I am looking for any way
>to minimize the ever increasing painful experience of maintaining this
>product's CVS repository.  The idea of branching directories separately
>seems like it would be a reasonable solution to the disastrously painful
>methodology they have today.

>What would you suggest instead?  Separate repositories for each application?
>I don't even want to think about how painful that would be.

>--- End of forwarded message from address@hidden

Although I suggested a way of doing the type of sharing you asked about,
I don't recommend it.  The reason is the classic one:  Introduce a change
to shared source code, you risk breaking the branches that don't appear
in your workspace.  Recovery options are to test and potentially repair
all the other branches (which is equivalent to porting a new feature to
each branch), or to make a copy of the shared code before you modify it
(and bloat the product), or to build other weird backward compatibility
hacks.

You might consider changing your code reuse paradigm to link-time reuse,
rather than compile-time reuse.  If you can plug in different libraries
or even object files to build the variants of your application, then you
may well discover a number of benefits.  Among them is a more efficient
build system because shared objects need be built once, not once per
variant.

Unfortunately, achieving this type of reuse is a long and painful process.
The conversion often involves redesigning the product to find the abstraction
points to facilitate the customizations in the right places.

"My tool of choice for software reuse was the editor until I inherited
60,000 lines of code from someone who felt the same way.  Now my tool of
choice for software reuse is the linker."  -- me, ca. 1989