From ClearCase to Mercurial and now to Subversion. Should I be worried?_问答_开发者

When I started my current job, I spent a year in ClearCase hell. Everything was kind of like Mordor in winter, only without the laughs. Then we started using Mercurial. Within about a day and a half the clouds moved away, the sun shone, birds started singing — or were those angels? I asked if this was heaven, and Kevin Costner said "No, it's ~~Iowa~~ Mercurial."

Now I'm moving to a company that uses Subversion. Should I be afraid? I've heard good things about Subversion, that it's better than Vault (which I hated) and way better than ClearCase. I've read many of the discussions here on SO, but I keep coming back to Joel Spolsky's implicit declaration that if I use Subversion I will incur brain damage. I'm prepared for a little bit of brain damage, but does anyone have adv开发者_如何学Goice on how to minimize the shock and loss of graymatter?

Moving backwards will make Subversion seem somewhat primitive, but it's generally easy to use and robust, if not as feature-ful. I think the biggest difference between moving from a modern DVCS like Mercurial to Subversion ("CVS done 'right'") is that Subversion uses the file system as an analogy for everything:

In Subversion, you "branch" by literally copying all the files from your "trunk" directory into a new directory in "branches".
Likewise, to "tag" a revision, you literally copy all the files from "trunk" into the "tags" directory.

These operations aren't really tags or branches, but the "tags" and "branches" directories are named that by convention.

You also have to be more careful, because committing any changes will push it to the main repo for everybody to see. An accidental commit can break "trunk" for everybody, leading to unhappy situations.

Also, be prepared for slow operations when you have to do everything over the network.

Much like clearcase - a lot of the joy or pain of svn isn't the tool itself but rather the implementation (or lack of). out of the box clearcase is virtually unusable, with an army of smart people administrating it and setting up the whole process it goes from worthless to just crazy expensive and mildly traumatic.

you'll be fine on svn. You'll miss hg, but should be able to get your work done with minimal fuss. If you aren't - blame the guys running the show, not the tool.

Some svn admins use a hook to prevent commits from clients that don't support the svn:mergeinfo property, the git and hg connectors wouldn't work in those implementations. Not that mergeinfo is that useful... it's totally worthless if you cannot count on it to be there.

After years of working with Subversion and now with Mercurial, the main difference for me is branching. I wouldn't like to go back to Subversion, I would miss it.

But after all you can use Mercurial on your local disc (even in the directory which is the checkout of the Subversion repository), maybe in the near future you can convince the right person and then the sun will shine again...

Try hgsubversion as a client, that will at least allow you to do your own experimental branches, local commits, shelve and a couple other nice Hg features.

Sometimes I've had difficulties with imports of large repositories, however, in which case I switch to hgsvn and use "hg-importsvn --local-only" on a subversion working copy. It requires an svn client. I recommend Slik SVN.

Both tools allow you to push back to the svn repo but they differ in how they operate.

I have to admit, I use hgsvn more often even though I like the concept of hgsubversion better. The import process just isn't reliable enough yet.

There is a difference of opinion between the Distributed Source Version Control (DSVC) world (git/mercurial/et al) and the CSVC (Centralised...) as to which is better.

Some like DSVC method of check in locally often, but only ever push "working" code to the central/master repository.

Some like the CSVC method of all commits are immediately visible to everyone, but the code in the central repository might not always work.

Ultimately, the choice is personal, and I would not get too worked up about it, although I will say that I think that DSVC works better for larger groups, and it probably also works better for a continuous integration setup. But, just as you can always write COBOL in any language, so too with source control can you make it work the way that you want, centralised or distributed.

What is more of a concern for you is what is the company culture? Do they accept the svn repo can be broken at any time, or do they demand that the svn repo always be working? That is the biggest delineator, IMO, as to whether or not you will preserve your sanity.

There is a svn-hg connector.

I use Clearcase at my current company and keep my fine-grained commits in a hg repo.