Date: Sun, 11 Feb 1996 17:05:17 -0800 (PST) From: Julian Elischer <julian@ref.tfs.com> To: nate@sri.MT.net (Nate Williams) Cc: karl@mcs.com, hackers@FreeBSD.org Subject: Re: CVS usage question Message-ID: <199602120105.RAA00244@ref.tfs.com> In-Reply-To: <199602112322.QAA17568@rocky.sri.MT.net> from "Nate Williams" at Feb 11, 96 04:22:57 pm
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.. > > 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.. > > 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 > ... > # cvs update -Pdr RELENG_2_1_0 are all the options needed? > > > 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. He has TWO cvs trees he has a single checked out tree. If I were doing this: (and I will be soon so I'm interested..) I'd expect it to work somewhat like as follows.. I'd do a cvs update to my checked out tree, using the SUPPed tree, then I'd do a cvs commit to the local cvs tree. that would (after changes) bring in merged updates into my local cvs tree I don't know enough about CVS to know all the ways of doing this, but I saw Peter doing similar using two CVS repositories on differnt machines. The checked out tree always had the merged code, with both new FreeBSD changes, and local changes, and the local CVS tree got these updates. As I said.. I have no idea how he was doing this.. > > > 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 > > > 3) To be able to SUP a new "Cvs" update *WITHOUT* destroying my local > > changes (one of the problems I have right now with SUPping -STABLE > > is that I have to be most careful where I set up as the target, and > > how I merge things -- this will get intolerable if I try to mirror > > daily and offer a SupX server...) Usinf only one CVS tree (and SUPing it,) I never check my changes in to it. I use cvs diff -c to keep a diff file of all my changes relative to the baseline and occasionally I shi[ that file to Freefall and commit it. > > The only solution in the current schema I'm aware of is this: > a) Checkout a version from whatever version you wish to modify the bits. > b) Modify the bits. > c1) As the bits change in the release, use 'cvs update' and such commands > to keep your bits 'in-sync' with the changes being made to the tree. what I do when the changes are in testing > OR > c2) Once you've made your local-changes, try to convince the CVS folks > of the validity of your changes so that you don't need to go through > the hassle of c1. what eventually happens if I think it's a good change.. of course you can have several checked out trees, each with a different set of changes in them. > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602120105.RAA00244>