Date: 13 Feb 96 11:56:05 GMT From: peter@jhome.DIALix.COM (Peter Wemm) To: freebsd-hackers@freebsd.org Subject: Re: CVS usage question Message-ID: <peter.824212565@jhome.DIALix.COM> References: <199602120105.RAA00244@ref.tfs.com>, <199602120115.SAA17779@rocky.sri.MT.net>
next in thread | previous in thread | raw e-mail | index | archive | help
nate@sri.MT.net (Nate Williams) writes: >> > Unfortunately, most of the goals are un-reachable, but I'll comment on >> > them anyway. >> >> Haveing watched peter wemm at work with this, I have a suggestion >> about how to do this.. talk to peter about some of how he was >> achieving this.. >As I understand it (Peter, jump in here anytime), he was using a local >version of the CVS tree and a remote version of the tree. However, both >versions were of the same lineage and never deferred from one another >except for time. Exactly.. And there is the odd "gotcha!" waiting to bite you as well, doing it the way I do. >> > # cvs update -Pdr RELENG_2_1_0 >> are all the options needed? >If you want the stable bits, yes. Yes, and if you want -current, you need the -Pd as well. I personally use "cvs -q update -d -P -A", with the -A being to release any accidental sticky tags that I occasionally set for checking older code.. >> > > 2) To be able to check *in* to a *LOCAL ONLY* branch changes which >> > > are in fact local, and incorporate THOSE into the extractions I make >> > > (I realize the risks inherent in doing this with version mismatches, >> > > but the places we change things aren't likely to be subject to >> > > revisions by the primary developers). It would be ideal if these >> > > revisions could then be blocked from SUPping by others (if not, I'll >> > > need two code trees -- blech). >> > >> > Simply checking out a copy of the sources in a spot in your tree, and >> > then modifying the bits in that tree and checking them in will work. >> > However, as soon as you re-sup the CVS bits from freefall your changes >> > in the CVS tree will be over-written. >> >> I notice peter doing this when I visited him and >> maybe someone else who knows CVS better than I, can explain. >See above. I also don't think Peter checked in the changes to the local >tree, but he can comment on that. Yes. I never commit locally. I have used a RCS tree locally though to keep track of the overall changes... This is only really short-term though. % ls -F CVS/ Makefile RCS/ fsdb.1 fsdb.c obj@ I dont use this very often though, only when I significantly diverge from the FreeBSD version for local reasons or for my Real Job. >> He has TWO cvs trees >> he has a single checked out tree. >As I understand it, he used the local CVS tree for quick reference, but >committed his changes against the remote CVS tree to avoid the grief of >bad packet loss on the international lines. >However, all of this assumes that the tree will eventually be 'synced' >up, so you can't keep local-only changes in the actual CVS tree. You >*can* keep them in the checked out copy of the sources, but they aren't >in the actual repository. Yes.. And there's the first gotcha! The CVS/Entries file records the revision you checked out, and the timestamp it put on the file. If the timestamp changes, it compares the revision to see if you've actually changed it, or whether it's just a "touch". Once you edit a file locally, it sees the timestamp has changed, compares it, records it as "M" (and caches that with the "last checked" timestamp). If the revision in the repository changes, it's merged. If you do a "remote commit", your entries file is updated to the new version number (say 1.6 for example) and the new timestamp is recorded. The next time you do a "cvs update", it sees the old local revision (say 1.5), and since 1.5 != 1.6, it replaces your freshy committed version with the old one. "Gotcha!" You have to do a sup or wait for the next CTM delta to get your commit back. I am very aware of this when I work and keep this in mind, so I rarely get caught. If I do and it's a problem, I do a "cvs -d freefall:/home/ncvs update filename.c" to get it back and be careful to not do an update until the next ctm delta arrives. >> > > The goal here is to be able to, say, extract a "usr.bin/login" from >> > > either our private change tree OR from the standard -STABLE tree. >> > > Is this possible while SUPping updates for the CVS masters? >> > >> > Nope, because the idea of SUPping the CVS bits is to guarantee that you >> > are getting the *exact* same bits as everyone else. If the bits are >> > different on your site vs. the site you are supping from, SUP will >> > notice the discrepancey make sure you get a copy of the 'master' file on >> > site. >> >> so you need two CVS trees, only one of which is updated >At which point you make it *very* difficult to keep both trees in >sync. since they never converge to the same code. If the trees >eventually converge it's not a problem, but trying to keep both in >sync. is a non-trivial problem. I have often wondered about the possibility of doing a weekly sup/ctm checkout of the "live" source, and then doing a "cvs import" into a local tree, and doing a "cvs update -jFREEBSD:yesterday -jFREEBSD". This is a good way to excercise your disks for a few hours, but it would allow you to have your local changes under CVS control and have FREEBSD on the "vendor branch". I think this would be workable if you: 1) have a lot of disk and CPU, and 2) need to do your own local development but still track (say) -stable, and 3) are tracking a slow-moving tree like 2.1-stable Once 2.2 became stable, you could flip over to 2.2-stable and have a big merge and relatively quickly roll in your local developments. >Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?peter.824212565>