Date: Thu, 29 Feb 1996 14:48:55 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: nate@sri.MT.net (Nate Williams) Cc: terry@lambert.org, nate@sri.MT.net, dufault@hda.com, hackers@FreeBSD.ORG Subject: Re: How to use the sup'd CVS tree? Message-ID: <199602292148.OAA12292@phaeton.artisoft.com> In-Reply-To: <199602291837.LAA12125@rocky.sri.MT.net> from "Nate Williams" at Feb 29, 96 11:37:53 am
next in thread | previous in thread | raw e-mail | index | archive | help
[ ... ] > > 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]). > > Having multiple irons in the fire is *very* typical of everyone. :) Maybe for people with commit privs, who tend to work on BSD to work on BSD. Not for people without commit privs (like me). I suspect that the majority of people without commit provs work on one or two things and don't tend to impact more than 3 or 4 files at a time. > > 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. > > Actual, the CVS bits are updated *all* the time, and unless they've > changed things everytime you connect it scans the local and remote trees > to determine which bits need to be sent. This is different from the > non-CVS trees which are scanned at regular intervals to same time. It > *might* be a good idea to run supscan on the CVS tree if freefall is > getting *lots* of CVS sup traffic. The problem is the "sup.freebsd.org" DNS alias suggestion to rotor the SUP server actually assigned. If implemented, you have to be careful that going from one SUP server to another doesn't *ever* put you back in time. Remember the "interesting" problems I had? They were the result of going back in time on SUP from sup2 when Jordan requested people get off the main SUP site. > > > > 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. > > A little frustration showing here Terry? *grin* No. It's just that people with CVS access and no commit privs who intend to do work need to work slightly differently from people who can checking on freefall and see their patches show up in their next SUP, if they want any kind of history control or source control at all on their local code developement. The only frustration I've had lately is trying to keep my SMP and FS code trees logically seperate, but simultaneously applied to my local kernel (third source tree and local branch tagging on two more trees). > > Don't get discouraged. The wheels move slow, but they do move. > > Boy do they *ever* move slowly. A little frustration showing here Nate? 8-) 8-). > > > 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. > > That's what I said. :) You didn't suggest tagging. 8-). > > 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. > > However, the difficulties with this is that your patches are sometimes > difficult to apply if the sources in your non-updated local tree are > changed in the master tree. This is where an integrated CVS/sup > protocol would be a 'good thing', but is also *really* hard to do. Right. I have been bit more than once on this because of the latency in SUP on modifications I made locally that conflicted with updates I didn't have yet. This calmed down somewhat when I got the newest version of CVS and I no longer had to sed-hack the sticky tags in for each checkout of the top level tree (I still think the "special" tag "HEAD" needs to set the tags to the most recent rev on the checkout -- that would have solved all of my problems with patch mismatches 6 months ago). 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?199602292148.OAA12292>