On 10/5/06, Steve Martin <sm.drdc@gmail.com> wrote:
> [EDITED]
> It worked perfectly like CVS always has, which subversion never has for me
> or a lot of the others on this list.
>
> So... all I'm asking is, what is so great about subversion that would make
> people want to give up the tried and tested SCM system, for something that
> seemingly has so many problems?
>
> And the previous SVN setup was on RHEL 4, and the current CVS setup is on
> RHEL 4. I'm certainly not a noob to this kind of thing, and did RTFM before
> setting subversion up, but it never worked for us like advertised, while CVS
> worked exactly like CVS always does... import a file, only IT'S rev changes,
> not everything in that dir or the entire repo...
Having used CVS for a long time myself I'm surprised you haven't met
some of the CVS bugbears.
- non-atomic commits (how's that broken build workin' for ya)
- unversioned directories
- untracked renames, copies and moves
- very slow tagging and branching.
My office is on a different continent to our repository and one thing
CVS isn't, is efficient in it's network usage.
That said, we're still using CVS. I've been unable to sell the team
(and myself in all honesty) on the immediacy of our need to move to
Subversion.
Some things I'd like to see (and some are coming).
- Merge-tracking
- revision aliases (it's easier to remember 'that_day_in_may' than r18357).
- Forward tracking of revisions from a URL@revision. I want to see
where filex was moved to and what changes were made. It's not enough
to just see where it was moved from.
- atomic renames.
- ability to configure the server and client not to compute diffs
based on mime-type. Some types just produce awful diffs and for the
minute gains in space/transmission the cost of computation is
prohibitive.
Things that I've had to wrap my head around and accept as reasonable.
- A repository revision # is a good thing. It immediately prevents a
check-in that might break the build purely because someone checked in
an incompatible change since you tested.
- Branching and tagging as folder copies. This one's tougher since
it's a mixed bag, it munges the namespace with folders that aren't
real development artifacts (trunk, branches, tags, etc). I wonder if
this wasn't the best decision (probably the simplest though). You
can't argue with the fast copies, and deletable branches and tags.
- Pristine copies. Damn that's a lot of diskspace used up. Yeah but
you can revert extremely cheaply in many cases and you're sending
diffs in boths directions. Aw hell, realistically disk is cheap
enough that most non-video-production projects are never going to
care.
There's better, more granular security as well. I'm sure there's
plenty I've missed.
We'll be moving and I believe it's not if but when. And that when is
probably soon after merge-tracking is complete and someone else has
walked the mine-field of its first release.
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 5 03:37:28 2006