Date: Mon, 5 Aug 1996 16:31:31 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jdp@polstra.com (John Polstra) Cc: terry@lambert.org, freebsd-hackers@FreeBSD.ORG Subject: Re: Announcing CVSup: Intelligent SUP Replacement Message-ID: <199608052331.QAA12309@phaeton.artisoft.com> In-Reply-To: <199608052250.PAA17655@austin.polstra.com> from "John Polstra" at Aug 5, 96 03:50:47 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Do you happen to have a small writeup of local vs. remote changes for: > > > > 1) get source tree using CVSup > > 2) Make local changes using a tag > > 3) Make more local changes using a second tag > > 4) Update source tree with remote changes > > 5) Merge updated code with tags to get new versions of tags > > Not really, but I'm glad you brought this up. I've been thinking > a lot about the logistics of local modifications, and I could use > some advice. > > First: Terry, I'm sure you understood this, but for my own peace > of mind I want to clear up a potential source of misunderstanding > in the way I worded that part of the announcement. I think most > people will understand what I meant, but I don't want to confuse > anyone. When I said it can merge new deltas from the remote side > with deltas added locally, I meant this: If you've added new deltas > A and B locally, and somebody else has added new deltas C and D > remotely, you'll end up with all four, A, B, C, and D. It will > _not_ do code merges to combine two sets of changes into a single > delta; i.e., it doesn't do what "cvs update -j 1.1 -j 1.2 foo" > does. Right. I expected that you would have to do that locally/manually. > Now, on to the logistics ... If I add, say, revision 1.15 locally, > and somebody else adds a revision 1.15 remotely, something has to > give. So we need a set of conventions, probably supported by some > small changes to cvs itself, to avoid those kinds of collisions. > My current thinking is that local modifications need to be made on > their own branches, and cvs has to be changed so that it won't > create those branches without a special option. Something like > this: > > 1. Stake out a range of revision numbers that is reserved for local > modifications. For example, we could say, branch numbers >= 1000 are > reserved for local modifications. This would include all revisions > a.b.1000.d, a.b.c.d.1000.f, a.b.c.d.e.f.1000.g, and so forth. > > 2. Modify CVS so that it would never create the reserved revision > numbers, except by explicit command. > > 3. Further modify CVS to add an explicit flag for creating a new > reserved branch. This would probably be a flag to the "tag" and "rtag" > commands, similar in spirit to the existing "-b" flag. > > Under this scheme, you could create your local branches at will, commit > to them freely, and be assured that updates from the remote repository > would not clobber them. > > I've looked at cvs, and this would be pretty easy to do. Do you > (all of you out there who are interested) think it's a workable > approach? Any better ideas? OK, what about revision history? Specifically: 1) main line source tree 2) Terry makes local revisions 3) import Terry's local revisions into the main line source tree to make an updated main line source tree 4) resulting main line tree contains 'N' additional revisions to ufs_vnops.c (or whatever) I can't see that a reserved tag ID would help in this case, since the merged version needs to drop the tag. This seems like it would require more than a little work on cvs... basically support for bringing the local stuff back into line after the local stuff was remotely merged... a "CVSup-style diff" for insertion into the main line tree, maybe? How seperate is the insertion code? Could it be run locally between two trees? It seems like this could help out with keeping the SMP tree a bit more up to date (and any similar work). As far as identifying local imports, a CVSup'ed CVS tree should probably imply that local modifications are to be seperately tagged in any case; any local modifications that modify files that are also modified on the main line. I think it should require that you explicitly turn this off. The implication should be done by flagging the collection somehow as having originated via CVSup or other modification-level mirroring (I know, I know, there isn't any...). There should maybe be a new top level command flag for tag/rtag (like you suggest) for tripping this flag off... but default after a CVSup should probably be "on". > > I would also like to see a collection that carried administrative files > > for SUP/CVSup that was used for sample files and never changed ID so that > > you could track the changes. If comment characters were supported in the > > SUP file, you could comment the collections you didn't want from the > > universe of available collections, and: > > > > 1) SUP collection file > > 2) Merge local changes (comments and local location and base) via > > CVS command (Item #5 in process above) > > 3) SUP the rest using never-stale information > > I like this idea a lot, although I don't think it'll work out-of-the-box. > SUP files do support comments (with a leading "#"). But cvs can't do > the kind of merge you'd need. It only merges on a line-by-line basis; > it couldn't merge a local location and base into a new collection line > from the remote site. > > Another possibility would be to add a syntax to the supfiles for > specifying global overrides of individual parameters in the collection > lines. E.g., at the top of the supfile: > > $override host=cvsup2.freebsd.org prefix=/home/terry/cvs Yes! This is what I wanted anyway, but I didn't want to sound greedy... 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?199608052331.QAA12309>