RE: CVS questions

[Arthur Barrett]

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