Date: Sun, 11 Feb 1996 18:15:52 -0700 From: Nate Williams <nate@sri.MT.net> To: Julian Elischer <julian@ref.tfs.com> Cc: nate@sri.MT.net (Nate Williams), karl@mcs.com, hackers@FreeBSD.org Subject: Re: CVS usage question Message-ID: <199602120115.SAA17779@rocky.sri.MT.net> In-Reply-To: <199602120105.RAA00244@ref.tfs.com> References: <199602112322.QAA17568@rocky.sri.MT.net> <199602120105.RAA00244@ref.tfs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. > > Since CVS allows modification of any bits that are checked out, there is > > no way to prevent you or anyone else from modifying these files short of > > the unix allows it now with permissions. > > however you can make sure that people can't check back in again.. Not w/out modifying the permissions of the files. > > For stable bits: > > # cd /usr > > # rm -rf src > > # cvs co -r RELENG_2_1_0 src > > doesn't have to be /usr/src.. could be ~xyz/src True. > > ... > > # cvs update -Pdr RELENG_2_1_0 > are all the options needed? If you want the stable bits, yes. > > > 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. > 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. > > > 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. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602120115.SAA17779>