Date: Thu, 29 Feb 1996 15:11:27 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) 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: <199602292211.PAA12340@phaeton.artisoft.com> In-Reply-To: <4345.825628593@time.cdrom.com> from "Jordan K. Hubbard" at Feb 29, 96 01:16:33 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. > > I'm totally serious when I say that I'd be very interested to hear > your ideas on this. I'd be the first to say that our current source > code control and distrubtion picture could be a lot better and more > intuitive than it is, but the old problem of having to make due with > the materials available has generally taken precedence over > engineering ideals. > > That's not to say we can't roll our own replacement (or adapt an > existing system to our needs), but we should at least be clear on the > design parameters of what we'd like, first. The whole CVS vs P3 vs > ??? issue will be coming up fairly shortly anyway, trust me. It's > not a bad time to be thinking about what we'd _like_ as opposed to > what we're forced to settle for. OK. The biggest thing has got to be the ability to reapply local patches without a checked out tree. This is the inverse of the 1. sup 2. checkout 3. modify 4. sup 5. update 5a. resolve conflicts, if any Process. What needs to be supported is: 1. sup 2. checkout 3. tag 4. modify 5. update using some process other than SUP 6. resolve conflicts if any The difference here is that it would let me locally have a tree with different sets of modifications with the modifcations seperable. Ideally, I want a modification tag, so I can check out a tree, and then say "give me this set of modifications and that set of modifications" and get something buildable. Really -- I want a current tree and a tag that means "current tree plus modification" that gets conflict resolved on each update, with each set of modifications resolved on a project-by-project basis. I don't know how unique I am -- I'm doing active developement without commit priviledges. Contrary to Nate's implication, this is not sour grapes; I fully understand the political climate that led to this, even if I don't fully agree with it in all respects (the Lite2 code integration *is* something I agree with). It seems to me that with the SUP/CVS gates open wide, a *lot* of people are going to find themselves in the same situation I'm in, in terms of not being able to turn around tree modifications by having them committed before they need to make more modifications. A modification tag mechanism of some kind would let me seperate out FS patches from SMP patches from NFS locking patches, etc., so that they could be submitted seperately, but so that I could use them in combination locally. For instance, the move to better than low granularity locking in SMP requires both the SMP and the FS patches so that I can push down the reentrancy mutex into each of the system calls instead of leaving in the trap code handling. To make local progress, I must have both, even if the core team only integrates one. I am faced with the choice of an all-or-nothing patch submission because the patches are logically seperable, but the tools won't support it. I've been thinking that a partial soloution is to use a translucent FS so that modified files are in a seperable tree subset. The problem is that I still can't resolve the branch dichotomy in the files to let me seperate the changes into logical units (the vfs_syscalls.c is a particular problem because I am ignoring the interrupt and fault kernel reentry and concentrating on the trap code for now). I'm afraid it really wants a much larger tool than CVS. 8-(. 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?199602292211.PAA12340>