Paul Sander wrote :
|| >--- 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.
Careful, Paul. That's logic leap is unwarranted. Unmergable today
does not have to mean unmergable forever. Writing a merge tool is
certainly a worthy approach, if it is possible. Even if CVS were
augmented to provide better support for unmergable files, converting
a file type from "unmergable" to "mergable" would permit you to use
the more convenient concurrent development methods on that class of
files.
But, there haven't been a huge rash of alternative merge tools
showing up: either everyone using odd file types is lazy, or the more
common odd file types are really hard to write merge tools for.
Having CVS provide better support for not-yet-mergable files is
worthy of consideration.
--
Anyone who can't laugh at himself is not | John Macdonald
taking life seriously enough -- Larry Wall | [EMAIL PROTECTED]
