[prog] VSS to CVS -- looking for experiences and argumentation help

[Akkana Peck]

Like others, I'm only commenting on the CVS concurrency issue,
having not used VSS.

dominik schramm writes:
> This is a good point, I haven't thought of this. 
> However, I'm thinking of a large project like Mozilla right now, and
> there every module has (one or more?) maintainers who coordinate the
> commits to CVS. This means that also in large Open Source projects 
> -- at least that's the impression I get from reading the contributing
> how-tos -- there is rarely such a thing as completely uncoordinated
> CVS access, where everybody fixes bugs at will and conflicts arise on
> a very short-term basis. Is this correct?  Could the project even 
> survive if commits were unorganized?

When the Mozilla project started, commits were completely
uncontrolled -- 100+ developers all checking into the same tree at
any time of day or night.  Almost every checkin of any size hit a
file that had to be updated since someone else had modified it
recently.  CVS resolved most of those automatically, no user
intervention required; of the rest, maybe 75% were easily
resolvable, where CVS did most of it, but left a few lines which
needed to be merged by hand, usually pretty easy.

Only in a small fraction of checkins were the merges difficult,
and that was usually because two people independantly decided that
the algorithm in a file needed rewriting (oops! but that became
exceedingly uncommon as mozilla matured) or because two people were
making significant design changes in the same part of mozilla -- in
this case, usually the people involved had coordinated ahead of time
and knew that a merge would be required.  

If a project frequently has two people making significant changes to
the same file without knowing about each others' work, it might be
worth evaluating (a) could communication among developers be improved?
or (b) could the source code of the project be factored better?

Rasjid writes (along with lots of other good CVS advice):
R> In practice, there have never been any problems with the lack of a 'locked'
R> checkout.  In fact, there is no way I would voluntarily move to a 'single
R> user locks whole file' system

When I first started working with CVS, I was dismayed at the lack of
locking; I thought, like Dominik, that locking was a good way of
knowing which files were being worked on.  But after working with
CVS for a while, I concluded that that wasn't a problem; and I do
think that file locking is a poor means of communication, and
walking down the hall and chatting on IRC to say "Hey, I'm making
big changes in foo.c!" is much more effective. :-)

	...Akkana