Greg A. Woods wrote :
|| > Perhaps you could show me where somebody else says that. The Berliner
|| > paper seems to me to be about how concurrent development is possible,
|| > with some mention in the second paragraph about how locking systems
|| > like RCS and SCCS don't scale well. CVS seems to be about permitting
|| > copy-edit-merge in a freely available tool. I don't see anywhere
|| > where it is about forcing programmers to simultaneously working on
|| > the same file.
||
|| CVS was designed only with the copy-edit-merge paradigm in mind.
|| Clearly it doesn't force programmers to always make simultaneous changes
|| to the same files and I certainly didn't mean to imply that it does.
|| Indeed good project management outside of CVS is often focused on how to
|| reduce conflicts and the need for merges and there's nothing wrong with
|| this.
||
|| All I'm saying is that CVS forces developers to work within the
|| copy-edit-merge paradigm -- there is no option to use hard locks and
|| Berliner justified this by showing that there has been not real need for
|| locks in their experience (and we can now amplify his conclusion though
|| the ongoing half-dozen years of experience a wide variety of people have
|| had with CVS).
The paper does not consider unmergable files at all. It is only
talking about the sort of files for which copy-edit-merge does work
well. It is a very big leap to say that there is deliberate intent
to require only concurrent operation on unmergable files as a design
goal of CVS. Instead, this is exactly the sort of situation which
Berliner anticipated when he talked of the open sourcing of the code
so it could be enhanced to meet broader needs.
--
Anyone who can't laugh at himself is not | John Macdonald
taking life seriously enough -- Larry Wall | [EMAIL PROTECTED]
