Sergei, I suspect that this thread is heading OT - but I (tried but) couldn't resist throwing in my own 2c.
> > cvs up -j v1_2 -j v_1_2_1 > > > > Of course, obviously, that's what I would call it, too. > > The problem with CVS is with repeated merges, -- too many manual > bookkeeping. And yes, I regularly do merges in CVS so I do know what > pain it is, even with some additional automation. Yes and that is why CVSNT has mergepoints, and since CVSNT began as a simple fork off CVS there is little cost to crossgrading. > No, almost any recent tool handles branching and merging better than > CVS. Even CVSNT and SVN are better, and in distributed VCS'es such as > bzr, git, or mercurial, branching and merging are natural and simple. We've just finished our first stable of the EVSCM project (was CVSNT 3.x) which supports SVN and CVS/CVSNT clients and in theory the open source EVSAPI can support any number of other clients. There is absolutely NO difference between CVS and SVN or any of these other clients where 'branching and merging are natural and simple' - it's just that some users like to work with one 'user interface' and others find a different 'user interface' more easily understood - all these clients do is provide a different user interface to the same raw data and services of the SCM server no more and no less interesting than the debate about WinCVS vs TortoiseCVS. All any debate about one user interface to another does is detract from the importance of SCM itself, and particularly the need to ensure that SCM supports the business in tangible and measurable ways. Regards, Arthur Barrett
