Re: Again: multiple vendors

[Kaz Kylheku]

On Sun, 6 Mar 2005, Baurzhan Ismagulov wrote:

> Thanks to all for comments and suggestions!

The CVS vendor branch feature has a broken design. At best, it can be
used to track new versions of the original baseline that was used to
create the repository with ``cvs import''. Even for that, it is
troublesome.

The first problem is that ``cvs import'' operates directly on the
repository. It does not create a sandbox which you can inspect for
differences against the repository and possibly throw-away, if
necessary, or commit if you are satisfied. In other words, go through
the regular pre-commit review. Secondly, you can end up with a
half-baked main trunk, in which files that are not locally modified are
replaced by new head revisions from the vendor branch, but files which
are locally modified are not replaced even if new changes exist for
them in the vendor branch. I.e. the most ``obviously safe'' vendor
changes are applied to the main trunk, and the rest you must do by a
manual merge, until which is done, you have inconsistency.

The second problem, the huge one, is that vendor branches all shoot
from revision 1.1 of every file, because they all share the 1.1 digits.
Branch 1.1.1, 1.1.3, 1.1.5, ... all are based on 1.1. This assumption
means that all the teams have exactly the same starting baseline that
they are patching, forever. What's ironic is that vendor branching
plays weird games with the RCS structure, on top of what normal
branches do, in spite of providing fewer features. There is that
question of the strange version 1.1.1.1 that is exactly the same as
version 1.1. You don't see this in a normal branch. If you create a
regular branch off version 1.3, you don't get some 1.3.1.1 version of
the file. You get /no/ new version of the file until you commit
something to the branch, and /then/ you get a version node like
1.3.2.1. (Or 1.3.4.1 if the branch number is 1.3.4, etc).

In the Meta-CVS version control tool, I implemented a tool for
third-party-source tracking that uses regular CVS branches underneath.
(Meta-CVS does not even have an ``import'' command, to avoid confusion.
The underlying ``cvs import'' is only used when one creates a
repository for the first time from some sources, and that command is
``mcvs create'').

In Meta-CVS, to track sources from a third party, first you identify
what baseline they are using. In the ideal case, it corresponds exactly
to some tagged baseline in your repo. So what you do first is create a
branch from that tagged baseline. 

Now that you have a branch from the baseline that the third party
patches are made from, you use ``mcvs grab -r <branch-name>'' to bring
the outside code to the tip of the branch.

What ``mcvs grab'' will do is convert the current directory and its
children into a Meta-CVS sandbox, by adding all the missing pieces that
a sandbox has. Moreover, it will analyze the files, and figure out file
moves and symbolic link reconfigurations.  Thus the sandbox will
basically express a minimized set of edits, including directory
structure edits, which one has to commit to sync the branch
to the new baseline. You can view diffs, make additional touchups, if
needed, and then commit the changes.  If you aren't happy, just delete
the MCVS/ subdirectory and the tree is no longer a sandbox. In fact, it
hasn't been touched at all. Until you commit, nothing happens in the
repository. And after that, nothing happens to your main trunk or any
other branch. Oh, and speaking of the main trunk, you can ``mcvs grab''
onto the trunk too. This takes care of a CVS FAQ: ``help, we branched
wildly, haven't used the main trunk in like a year, and now we just
want to replace the tip of it without merging''. No problem.

To merge the branch, you do it like any other branch. Of course, since
you are using ``managed branches'' in Meta-CVS which track what has
been merged, it's a simple command: ``mcvs merge <branch-name>'',
review everything and commit.  If you screw up the merge, just throw
away the changes, and then ``mcvs remerge <branch-name>'' will re-apply
the last merge.

When you merge from a branch, you can do some useful things, like
manually throw away some renames in order to assert ``we don't want
these directory structure changes being done on this branch, just the
content bugfixes''. The vendor can then continue providing patches
using /their/ modified directory structure, and they get nicely merged
down into /your/ directory structure. 

-- 
Meta-CVS: the working replacement for CVS that has been stable since
2002.  It versions the directory structure, symbolic links and execute
permissions. It figures out renaming on import. Plus it babysits the kids
and does light housekeeping! http://freshmeat.net/projects/mcvs