Re: SCMS question

Andrew Dunstan <andrew@dunslane.net>

From: Andrew Dunstan <andrew@dunslane.net>
To: Gregory Stark <stark@enterprisedb.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@commandprompt.com>, Bruce Momjian <bruce@momjian.us>, Warren Turkal <wt@penguintechs.org>, pgsql-hackers@postgresql.org
Date: 2007-02-24T01:32:09Z
Lists: pgsql-hackers
Gregory Stark wrote:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>   
>> I note also that CVS does have the ability to merge changes across
>> branches, we just choose not to use it that way.
>>     
>
> And the reason why, I assume, is because it's hard to grant access to CVS
> without granting access to do anything at all to the whole repository. And CVS
> is fragile enough that that's pretty scary. There are lots of ways someone
> could mess up a CVS repository.
>   

Every project I have been on that has used cross branch merge  with CVS 
has tied itself in knots. Branch and never merge is by far the sanest 
way to operate. This is true regardless of any privs issue.

The elephant in the room is that merging is *the* hard problem in SCM 
systems. Last time I wrestled with merge it was using ClearCase and 
drove me nuts.

> The distributed systems sound neat and do sound like they match our style of
> working. But they seem like a big leap for a project that's still using a
> buggy unmaintained pile of spaghetti code for fear of change. Subversion is
> the path of least resistance in that nothing has to change, we can choose to
> use new features if we want but otherwise it's basically a CVS 2.0 with a new
> name (and active maintenance).
>
>   

There is some truth in that. Also, many of the new systems have a little 
way to go on maturity - I'd like to see the dust settle some in this area.

cheers

andrew