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 _______________________________________________ Info-cvs mailing list [email protected] http://lists.gnu.org/mailman/listinfo/info-cvs
