Date: Tue, 6 Aug 1996 10:53:09 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: chuckr@glue.umd.edu (Chuck Robey) Cc: jdp@polstra.com, terry@lambert.org, freebsd-hackers@FreeBSD.ORG Subject: Re: Announcing CVSup: Intelligent SUP Replacement Message-ID: <199608061753.KAA13612@phaeton.artisoft.com> In-Reply-To: <Pine.OSF.3.95.960806000852.25864E-100000@fiber.eng.umd.edu> from "Chuck Robey" at Aug 6, 96 00:11:57 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I have a limited idea, and a somewhat limited understanding of the problem > (I'm reading avidly, but just getting used to cvs), but could I make a > suggestion? How about reserving numbers on the main cvs tree, for every > file you intend to modify, in advance? That way you'd not have the > problem of number collisions, no matter how many developers decided to > hack the same code at the same time, the one's that did it remotely would > HAVE to check in the get numbers. Actually, this is exactly the problem. The issue is not loose coupling of developers with commit access, it's allowing developers without commit access to have local version control on files the intend to submit. The tool allows the decoupling of the review process from preventing additional developement pending outcome of the review. Someone may implement 6 or 8 more things while waiting for the first thing to be reviewed this way. The local version control for local experimentation by developers with commit access is a bonus side effect. Another side effect is that it allows vendor branchine for derivative distributions, with change merge. This supports people who want to sign NDA and write a Buslogic driver (for instance), since it is not possible to take their code into account if they can't release it. 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?199608061753.KAA13612>