Re: CVS - setup reserved checkout

[Kaz Kylheku]

In article <address@hidden>, Bryon Lape wrote:
>Kaz Kylheku wrote:
>
>> CVS doesn't require hand merging.  When you perform a cvs update
>> operation, then new changes in the repository are automatically
>> incorporated into your working copy. Only when a conflict arises do
>> you have to do resolution by hand. Conflicts tend to occur rarely, and
>> are usually very easy to resolve.
>
>Conflicts are extremely easy to produce and may not be easily resolved.

Only in your FUD-filled imagination perhaps.

In the very worst conflict scenario, you simply back out your changes,
allowing the other developer's changes to supersede.

You then lose your work. But that's work you would not have been able
to carry out, had the other developer placed a strict lock!

That is the full extent of the damage in the worst case conflict scenario;
someone loses a bounded amount of work, which is a negative productivity
hit. If it takes more work to do the merge than to scrap your work and
redo it differently in the light of the new changes, then the only
economically feasible alternative is to scrap your uncommited work!

So there is an easy upper bound on the difficulty of conflict resolution.

You are grossly exaggerating the risk by saying that these conflicts are
``extremely easy'' to produde. In reality, it has a very small probability
of happening. If you multiply this vanishingly small probability by
the negative amount of work done (work lost), you get some number that
doesn't put so much as a dent in your overall productivity gain.

Further, that risk is minimized by doing fine grained commits, frequent
updates, and communicating with other developers. If you develop a
feature for eight weeks without incorporating other modifications to
your working copy, without breaking your work into finer-grained changes
that are separately committed, and without talking to anyone, you may
have a more difficult merge at the end. Heck, you might find that the
whole project had been canceled seven weeks ago; now there's a conflict!

Lastly, note that strict locking at the file level does not prevent
conflicts, because parallel development can still take place on separate
files. The project as a whole is being developed in parallel, and semantic
conflicts can still arise.  Full-blown parallel development without file
locks is simply the realization that unless everyone places a big lock
over the entire project for every single change, you are already doing
parallel development. So why not just remove the final obstacle.