[EMAIL PROTECTED] (Pierre Asselin) writes: > Sergei Organov <[EMAIL PROTECTED]> wrote: >> Preston Landers <[EMAIL PROTECTED]> writes: > >> > I'm poorly equipped to counter these arguments at the moment because I >> > have so little understanding of the topic myself. I just know from >> > experience at a previous CVS-using organization that in CVS it is >> > infinitely easier to deal with concurrent access and merging changes. > >> To tell the truth, CVS is not that good at merges, -- it requires quite >> a lot of manual housekeeping to do merges right. > > Yes, but it is adequate for the routine "sandbox" merges that happen > all the time in concurrent development, when someone else has been > editing the same files as you and beat you to the commit. This is > where Preston's users need an education.
That's in fact the easy case with CVS. The hard case is merging to/from branches that requires manual tagging in order to remember what has been already merged. > The sandbox merges tend to fall apart across refactorings, in > particular when large code blocks are permuted. However commits > of that type are infrequent. They just need to be planned ahead > of time by the team. In addition, merging over renames is really painful with CVS, -- entirely manual and error-prone work :( -- Sergei.
