>--- Forwarded mail from [EMAIL PROTECTED]
>[ 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.
Whoa. You just said that if I want to use CVS with unmergeable files, then
I must supply a merge tool for them. The trouble is that no merge tool can
be implemented for unmergeable files, by definition. So I'm afraid that
suggestion isn't very helpful.
>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.
Looks like it's time to look at Aegis again. It's been a few years since
my last look, and maybe it meets more of my requirements now than CVS does.
>> 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.
Could you expand upon that? In the past, you've discussed using tar or
using directory trees for version control, particularly for binary files
provided by outside vendors. This diff/diff3/patch thing seems to be
something new.
>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!).
Unfortunately, very few engineers doing product development seem to have
much interest in learning release management. They'd rather work on problems
that are more interesting to them and leave the code management (releases
and baselines) to someone else.
>> 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.
You have recommended in the past somehow combining CVS with another version
control system that's more capable of managing unmergeable source files.
I don't see what I've described differs from your recommendation.
>> 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 developers prefer the concurrency model where it's appropriate. It's
not much of a stretch to make it a requirement.
>> 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
I've been putting a lot of thought into that very thing, but due to time
constraints nothing will happen on that front for a long time. :-(
>--- End of forwarded message from [EMAIL PROTECTED]
