Date: Mon, 19 Aug 1996 19:50:44 +0800 From: Peter Wemm <peter@spinner.dialix.com> To: lite2@freebsd.org Subject: cvs tree preperation.. Message-ID: <199608191150.TAA03563@spinner.DIALix.COM>
next in thread | raw e-mail | index | archive | help
This kind of got away from me last time, lets see if we can sort something out and get it going. As for how we do it, we have several choices.. I'll re-list them and add some answers to questions I was asked last time... 1: same as smp tree. -current imported onto vendor branch. This looses -current's commit history, all of -current is in a single revision, and logs cannot be extracted. The lite-2 patches are applied to it, and periodically a new -current is pulled in. Once the conflicts from -current are resolved, a 'cvs diff -c -rCURRENT' will produce a patch that will be able to be applied cleanly to -current. The disadvantages would be that to get deltas/logs between -current versions, you'd have to write a script that takes your $PWD and uses that to extract the info from another tree somewhere. 2: use cvsup to copy the -current tree into /home/lite2's repository, and ADD a side-branch that cvsup will not touch (hopefully). This means the commit logs are available in the working source. However, this has some serious disadvantages, this only works for a short time before it becomes impossible to manage. The basic problem is that from the branch-point onwards, cvs doesn't remember which parts of -current you've merged in. So, if you do a 'cvs update -j HEAD', it will merge -current's changes into the lite2 branch, and you resolve the conflicts. However, if you again, next week do a 'cvs update -jHEAD' you get BOTH weeks changes merged together into the side branch. This means you get all the same conflicts AGAIN, plus new ones. cvs uses rcsmerge, and as this branchpoint-to-current delta gets bigger, the conflicts will get bigger (ie: 50 line conflict markers because of a whitespace change is not fun). 3: like #2, but place explicit markers on the current branch and use those for merging, instead of 'update -j HEAD', we import -current, do a 'cvs rtag MERGE1', and on the lite2 branch, we do a 'cvs update -jMERGE1'. Next time we sync with -current, we add 'cvs rtag MERGE2' and do a 'cvs update -jMERGE1 -jMERGE2'. That way we wont get super-conflicts and the same conflicts over and over again. I'm not sure how it would go in practice, I've never tried it befor. If somebody branches -current with the same $Id$ as the Lite2 branch is on, we're sunk. 4: Give p3 a shot (http://www.p3.com). P3 is designed to do this sort of merging, but it's quite different to cvs and will take a lot of re-learning. It isn't quite as flexible with diffing, but it can be done. It can do delta-by-delta merging, rather than simply merging the lot and fixing up the mess. However, what we gained from the better branch support we'd probably loose in re-learning time.... My thoughts are that #1 is preferable from a "known quantity" perspective, but #3 is probably more practical but at a risk of using a new tool (ie: using cvsup to generate the repository on freefall, from freefall). Doug? Jeff? -Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608191150.TAA03563>