[ On Tuesday, February 15, 2000 at 17:56:17 (-0800), Paul Sander wrote: ]
> Subject: Re: CVS File Locking
>
> He does not explore any cases where there are no viable merge methods for
> his source files.
Of course not. That's outside the scope of the problem being solved.
If you want to use CVS with un-mergable files then you must either use
binary choices when resolving conflicts or develop software that will
allow you to actually merge changes in such files. Ideally you would
also devise automated merging tools that could detect conflicts and thus
be integrated directly into CVS.
If you don't want to do that then don't use CVS.
> So, when merging isn't possible, something else is needed.
Yes, exactly. Some other tool other than CVS. :-)
> Hence,
> people demand a secondary method that applies generally. Locking is one
> method that is well understood and relatively easy to implement.
If that other tool uses locking then that's perfectly OK.
Personally I'd prefer a two-stage commit system (which gives concurrent
development capability without the copy-edit-merge paragim by pushing
the conflict detection and resolution to a different level where it
might better be handled for truely unmergable files). Aegis springs to
mind here.
> I have no first-hand experience with any shop that was willing to use
> two source control systems on a single project.
Well I do (for a certain class of projects where the primary source code
is easily handled by diff/diff3/patch) and I can assure you that it
works very well and isn't much of a problem at all.
It does require that the developers have a good understanding of release
management techniques and that they be competent enough to manage
several micro-projects in synchronisation with their central project.
However this isn't very hard to teach and anyone capable of programming
is usually able to learn the techniques (even if they're not always
willing to do so!).
> I have heard of one
> shop that has used two distinct tools for source control on the same
> project, but the tools were substantially similar (SCCS and RCS) and
> the project (the Unix operating system) was divided among many development
> groups who used the same tool internally.
That's an entirely different and un-related and much more difficult
problem scenario than what I'm talking about.
> Informal discussions with
> various people indicate a general distaste of mixing source control
> tools in a single development environment. So, the hybrid system
> seems to be both impractical and unpopular.
It would be in the scenario you've described.
> Abandoning CVS doesn't help promote the concurrency model, unless the
> new tool supports it.
I didn't try to say that it had to help promote the concurrency model! ;-)
> The final alternative is to generalize CVS.
No, there's no alternative there. What is possible is to base a new
tool on the CVS codebase (if anyone seriously believes that's a sane
thing to do -- I would strongly recommend a full re-write from the
ground up, perhaps retaining only some facets of the user-interface and
perhaps the server protocol). Obviously I'm not in the least interested
in working on such a project though and I would strongly prefer that
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
