Upgrade a CVS server to something else?

[David Kramer]

On 12/13/2010 10:26 PM, Matthew Gillen wrote:
> On 12/13/2010 10:03 PM, Edward Ned Harvey wrote:
>>> From: discuss-bounces-mNDKBlG2WHs at public.gmane.org [mailto:discuss-bounces-mNDKBlG2WHs at public.gmane.org] On Behalf
>>> Of Tom Metro
>>>
>>> Someone else has addressed this. SVN provides some raw functionality by
>>> which developers can implement tagging by convention. The big down side
>>> to SVN tags is that the VCS doesn't prohibit you from turning a tag into
>>> a branch - or in other words, making modifications to a tagged revision.
>>> Doing so would generally be considered bad practice, however I've never
>>> seen a developer violate the conventions in the 10 years I've been using
>>> SVN.
>>
>> More correctly, "doesn't automatically make the tagged directory read-only."
>>
>> I know, in organizations that I support on svn, we have a release process.
>> All the engineers sync up, somebody runs regressions, and if all the tests
>> pass, then we tag that release.  I make the tagged directory read-only.
>>
>> Later, if we ever need to respin, then we fork a branch from the tag.  Thus
>> leaving the tag read-only, and continuing to modify the branch.  Which will
>> later produce another tag.

This is a classic low-level-powerful-but-dangerous vs
high-level-user-friendly-but-limited tool dilemma. There is no universal
right answer.  Personally, I'll choose the more powerful low level tool
about 80% of the time.

In the case of svn, in the last company I used it in, I created a
pre-commit hook that would only let certain people commit files and
directories that met a series of regular expressions. Very powerful, and
very reliable.

There are legit reasons to dislike svn, but most people who hate svn do
so because they're hung up on the fact that their favorite SCM
implements branching and tagging in a specific way, and they can't get
their head around the fact that svn copy offers the same exact
functionality, implemented completely differently.

> With subversion and it's repository-wide revision numbers, you also have the
> option of creating 'tags' by just noting a particular revision number on
> your team wiki, perhaps with the full checkout command:
>  - Demo'd version Dec 12, 2010
>   svn co foo.bar://svn/proj/trunk@21023

In most environments that use svn, they're not using svnserve, but
through Apache.  That means you can put an actual URL to a specific
revision of the repository on your wiki.

> You can do most anything you want to do with just that revision number (e.g.
> create a branch from that revision).  The advantage is that you don't have
> to rely on convention to get the read-only status ;-)

Yup.  At my current company, we're moving to Mercurial (hg), and I'm
beginning to really like it.  It's like if svn and git got drunk at a
party together and nine months later hg was born.