Date: Thu, 29 Feb 1996 11:18:54 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: nate@sri.MT.net (Nate Williams) Cc: dufault@hda.com, hackers@FreeBSD.ORG Subject: Re: How to use the sup'd CVS tree? Message-ID: <199602291818.LAA11890@phaeton.artisoft.com> In-Reply-To: <199602291535.IAA11404@rocky.sri.MT.net> from "Nate Williams" at Feb 29, 96 08:35:09 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > I have now sup'd the cvs tree and have what looks like the -current > > release, and I can do "cvs gets", etc, locally. But I don't > > understand the process for working in -current and getting patches > > for -stable for local test. > > The easiest way is to checkout two trees on your local box of the stuff > you're working on, one for -current and one for -stable. (There are > other ways to do this, but I find this to work the best.) Yes. This is what you must do (I am locally running out of space because I have multiple irons in the fire, all of which have not been committed back to the core tree by people with commit privs; this is probably atypical [the multiple irons in the fire part]). > > 0. (Basic assertion I think is correct) There is no "cvs awareness" > > in sup, and sup will simply update my sup tree to match what is on freefall. > > SUP simply makes sure the 'bits' are the same at both ends. Nothing > more, nothing less. This is right. It is one of the most annoying attributes of the SUP/CVS setup. Really, you want the changes to come in as commit deltas and then recommit them to your local CVS tree so you can locally use things like vendor branches and revision tags. CTM doesn't buy you this either. > > 1. How do I "sup" again? I assume most info is kept in the local > > working directory, so if all I have is locally checked out modules > > I can go ahead and "sup cvs" when I want, and it is only when I > > want to commit my changes that I have to be careful. > > You can 'sup' all day long all the time and it won't matter 'as long as > you don't commit your changes locally'. This is a bad thing, since > those changes will go over-written as soon as you re-sup. So, the moral > of the story is to *never* commit locally. Typically, you only want to sup as frequently as the SUP server is updated divided by two so that you always get referentially valid bits. Since that's twice a day, the *most* frequently you want to SUP is once a day, and that's really only justufuable if you are actively developing. If you vary which SUP server you use, you must take into account propagation delay between main and leaf nodes. I believe all the SUP mirrors are sup'ing from the master server directly. If they are updating once a day, then you want to update no more frequently than once every two days if you are sup'ing from a DNS rotor list. Typically, the master server wants to update one time a day, and the slave servers want to update twice a day to allow a rotorred client to not smash bits by backing stuff out on a once-a-day SUP. Think of it as timing windows on protocols. You never want to get a SUP server that isn't *at least* as up-to-date as the SUP server you got previously. > > 2. Do I commit back on freefall and then get my updates in the next > > sup? > > That's pretty much how folks (modulo some stuff Peter's doing) are doing > things now. That might change in the near future, but I'll let Peter > spear-head that. This assumes you have commit priveleges. If you don't, you need to submit your patches. If they confict with things like the Lite2 integration (which has apparently not been done yet) or major work in another area, or if they take a long time to review because of their subtlety or complexity, it may take you a long time to get tehm committed. For instance, some of my FS patches have been waiting 8 months for the Lite2 integration. Don't get discouraged. The wheels move slow, but they do move. > > 3. How do I do local revision control, in conjunction with question > > 1? If I'm doing extensive work can I create a local branch so that > > I can keep local changes under revision control without having > > "sup" step on me? > > Nope. If you want to do local revision control, your best bet is to is > to use a non-shared (ie; local) CVS tree, and keep it up to date > locally. Either that or create a branch tree on freefall and do your > commits there away from the world. This still requires that all of your > commits be done on freefall. The easiest way is to tag a branch on a local tree snapshot and not update the tree. The diffs from the mainline source base are always available, and then can be applied to an untagged tree as patches. You can use the revisions tags in the file and a "cvs update" to detect and resolve conflicts. Be sure to either remove patches that are accepted from your local tree, or to check them in on the unbranched tree so that they are not reversed (this is important! I did this with the CD9660 FS!). > > I don't see how this would play with assertion 0 without creating > > branches back on freefall. > > You've got it. Or by submitting to a committer. > [ Again, the -A is un-needed but it clears out any sticky tags and > guarantees you've got -current bits ] Note: if you have played with things like the SMP patches, you will definitely need the -A to clear out the 28Oct94 sticky tag (for instance) that resulted from the CVS checkout for your playing. > > 5. Am I on the right track? > > Yep. Yes. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602291818.LAA11890>