Re: CVS questions

[Sergei Organov]

"Arthur Barrett" <address@hidden> writes:

> 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' 
[...]

Sorry Arthur, I don't follow. Those VCS'es I've talked about are
distributed and therefore are fundamentally different from
CVS/CVSNT/SVN. There is simply no server nor inherent central repository
in their model of operation, and there are concepts that are not
applicable to centralized VCSes. Well, one probably can use distributed
VCS as (poor) centralized VCS, but he will loose a lot of functionality
and convenience. For example, git has limited implementation of CVS
server that allows CVS clients to work with git repositories, but most
of the niceties of git are not available to CVS clients.

-- Sergei.