Date: Thu, 29 Feb 1996 11:37:53 -0700 From: Nate Williams <nate@sri.MT.net> To: Terry Lambert <terry@lambert.org> Cc: nate@sri.MT.net (Nate Williams), dufault@hda.com, hackers@FreeBSD.ORG Subject: Re: How to use the sup'd CVS tree? Message-ID: <199602291837.LAA12125@rocky.sri.MT.net> In-Reply-To: <199602291818.LAA11890@phaeton.artisoft.com> References: <199602291535.IAA11404@rocky.sri.MT.net> <199602291818.LAA11890@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[ Developing in both -current and stable ] > > The easiest way is to checkout two trees on your local box.. > 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. :) > > > 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. This is a *hard* problem to solve. We're taking the easy way out since no-one has stepped up to solve the hard problem. (Something like P3 may be a solution, but my tolerance for setting aside enough free time for experimeting with such things is rapidly approaching zero). > 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. > > > 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* > Don't get discouraged. The wheels move slow, but they do move. Boy do they *ever* move slowly. > > 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. :) > 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. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602291837.LAA12125>