Date: Wed, 5 Jun 1996 11:58:44 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: phk@freebsd.org (Poul-Henning Kamp) Cc: terry@lambert.org, sef@kithrup.com, smp@freebsd.org Subject: Re: Unix/NT synchronization model (was: SMP progress?) Message-ID: <199606051858.LAA29430@phaeton.artisoft.com> In-Reply-To: <1039.833999791@critter2.tfs.com> from "Poul-Henning Kamp" at Jun 5, 96 11:36:31 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >In point of fact, I have already prepared all of vfs_syscalls.c for > >the lock pushdown from the trap code, as described in my previous > >post, by making them single-entry/single-exit. I really don't see > >why the patches need to be all-or-nothing for you to even consider > >them in the first place... all that requirement does is make > >eventual integration more difficult (and thus unlikely). > > my words exactly. Except >I< think that >you< should do the work > of keep the issues separate rather than me trying to separate them. With respect, this is much more difficult for those of us who must do our changes locally and use SUP or CTM to keep up to date. Each time I pull an updated tree from my local mirror of the CVS tree, I must re-merge and re-integrate all of my patches. What you are asking me to do is to do this for multiple trees (which I'm perfectly willing to do for logically seperate structures). The problem arises for me when, for instance, I want to do work on something that requires an agregate of multiple patch sets to allow me to work on yet another thing. Because my code is locally not under source code control because of the way the mirroring operates, I have no way of producing a local source tree with an agregated set of local patches. Short of manually agregating them into a single tree, and then we have the problem you describe, where my patches aren't acceptable to you for seperate consideration. My motivation in doing these sub-patches is to get an agregate that I can use locally. It does me no good to lay out 8 pylons if I can't use them in combination to build an overpass. My motivation is what I build on top of the agregated patches, not the patches as individual small-scope changes. --- This is really a tools problem. We need some way of integrating CVS trees so that I can locally set a branch tag for each one of the various small-scope patches, yet still integrate updates to the untagged branch as incremental updates -- ie: as local checkin on the unbranched portion of the tree. Unfortunately, short of rewriting CVS, I don't see an easy way of achiveing an agregate (my goal) while maintaining seperable small-scope patches (your goal). I would be more than happy if you could suggest *anything* to get around this conflict: it would most certainly result in me providing the small-scope patches you want, without interfering with my ability to do my own real work. 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?199606051858.LAA29430>