Date: Wed, 26 Feb 1997 13:42:32 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: nate@mt.sri.com (Nate Williams) Cc: terry@lambert.org, nate@mt.sri.com, freebsd-current@freebsd.org Subject: Re: anoncvs server Message-ID: <199702262042.NAA28653@phaeton.artisoft.com> In-Reply-To: <199702261835.LAA29819@rocky.mt.sri.com> from "Nate Williams" at Feb 26, 97 11:35:18 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > If FreeBSD came in on a vendor branch initially, then it wouldn't touch > > anything else I had done locally. > > You're free to do that, but it requires the same sort of things Peter > does in the SMP branch. But, it means losing all of the history for the > FreeBSD changes. Depends on you you define the import process for a vendor branch. If you define it badly, you're right. > Either we provide you with a 'vendor' source SNAPSHOT, or we provide you > with the CVS repository. You can't mix/match what you want, simply > because it's 'not possible' to do automatically. I want a cvs repository that has a pre-imported "vendor branch" that contains the FreeBSD code, and the entire modifcation history of FreeBSD as modifications to the vendor branch. This would keep me from losing the history, letting me mix and match what I want. 8-). > > Alternately, if it came in with a > > predefined "magic tag", I could only make one change locally, and then > > wait 9 months (the current time outstanding for the layering patches > > being committed) before I could resonable reuse the "magic tag" for > > another change. > > I don't think you understand CVS/branches very well. The 'magic tag' is > a 'magic branch tag'. Yes, but in this case, it would be one I'd agree not to modify locally, not one that FreeBSD would guarantee not to modify remotely. It's the same thing, but the logic is inverted to let me personally maintain multiple concurrent branches locally without a "magic tag" per. > As changes are made in -current, you can either refuse to 'merge' them > into your branch, or merge them in, as has been done with all the YAMFC > changes you've seen. But, since *YOU* are the magic branch maintainer, > it is your responsibility to merge them in, nobody but you can do them. > In any case, these are the sorts of things you had to do in the past > anyway, it's just that CVS makes it (hopefully) easier to do these sorts > of tasks. This is unsatisfactory, because it means that you lose my modification history. That's no so important for a single set of changes, but for a set of interrelated changes, it becomes a bigger problem. > > With the "magic tag" approach, I can only have one set of dependent > > patches outstanding at one time. > > True, but you can't have everything. That's silly. I want everything. Why can't I have everything? It's just code... > What you have now is orders of > magnitude better than what you had to do before. And, assuming you've > kept things 'separate' *you* should be able to pull out the relevant > changes as needed. Yes; this is the seperate tree issue, given the lack of "magic tags". > Having N sets of 'depedant' patches is pretty much impossible in CVS > w/out N branches, and keeping N branches sychronized is an almost > impossible task. But, if you *really* want I'm sure John could give you > a set of 'magic branch tags' he won't touch. :) :) :) :) "Magic tags" themselves are a problem precisely because of this. And you still lose modification history. For instance, I make patch set 'A', then I make patch set 'B' which includes minor changes to patch set 'A' to make it interoperate correctly -- but patch set 'A' without patch set 'B' should not have these minor changes. That's the reason I sent the EEXISTS patches combined with the namei() layering patches, actually: the changes are significantly interdependent in 5 places, where the namei() is called for CREATE, and the transaction is backed out in the case that the namei() returned a vnode for an existing create/rename target. Those 5 places would need to be *unpatched* in the namei() patches if the EEXISTS changes were submitted later. As much as I'd like to change the code for single-entry/single-exit for all system calls, sneaking it in that way isn't the way to do it. Regards, 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?199702262042.NAA28653>