The argument which goes like this:
"hey if you want locking use another product..."
Doesn't fit the requirement for a centralized
repository for source code and web content.
Content, such as HTML and GIFs,
can not be merged. Source code can.
File locking is necessary for content unless
the project can be organized into
individual folders for each content
author -- this will not likely work any period
of time longer than one month.
Separating content and source code in different
types of change management systems is awkward at
best. Who wants to learn and manage two tools?
Not me. Not anybody.
If you think I'm fond of locking, read
http://www.devguy.com/fp/ProgrammersCanvas.
Locking is evil. But it's a necessary evil.
Of course once someone gets used to locking, they
will always lock files, regardless of whether
the files can be merged or not. These nimrods
will have to be shot because they will never
change their ways. The only solution seems
to be to tag which files can and can not be locked
(it should be on a file-by-file basis, not a
file-type basis).
CVS is missing other functionality regarding
locking -
1. It's not easy to create a report of the
files that have been locked, including
who locked them and how long they've been
locked
2. Locking is a hidden feature - nobody can
find it under "admin" (by design, probably)
I work on projects where CVS is used for content and
source code. Content people lock files
and the programmers don't. That's how it
boils down. The content people learn to lock
files once they slam into each other a few
times.
WebDAV may make this a moot point. CVS's
days may be numbered. They certainly are numbered
if CVS can't effectively manage content. It can't
handle UNICODE files either (that's my experience
anyway) and that is a big problem because XML
files can be UNICODE. XML will become the
dominant format for content, and the system
that best handles XML will win.
