What is the most annoying thing about the revision control system (SCM) you use?

Question

This question is not asking what revision control software I should use. Rather, I would like to hear what you think are the downsides of some of the SCMs you've used.

Websites and marketing material only highlight the advantages, but I want to hear from people who have actually used it what they think are the downsides.

Can you name some quality or behaviour you find annoying or counter-productive in an SCM you are using or have used?

Answer 1

I can confirm most of the stuff mentioned here about VSS.

I have been forced to use it. :-(

Answer 2

Even though SCM is probably one of the best things you can use in a development environment it always bothers me that (and these might be nit-picking):

• When someone else changes I file, I don't know about it until I commit or do an update.
• Merging is a pain in the ass.
• When other people suck at using it, it gets in the way more than it helps.
• It's too difficult to manage different branches, tags and trunks of the same app.

That's all I can think of now. :)

Answer 3

Subversion: the server is very robust, but there's no GUI admin client (edit: really needs to be one with a support option)

We switched from SourceUnsafe to Seapine SurroundSCM about a year ago; we strongly considered Subversion, but our repository administrator, who does a very good job, is not a command-line expert, and without a GUI admin client there was a huge hole in the way we could maintain our company's source control repositories.

FWIW, I think all of the SCMs have problems with terminology. This makes it even more hellish to switch SCM software when many of the users at our company are not software engineers with perfect memories. VSS calls directories "projects". Seapine SurroundSCM calls directories "repositories". (Subversion had some annoying names for things also but I can't think of what they are right now)

Answer 4

Here's my personal list. I don't claim that these points are incredibly well researched, but these are the major gripes I've had with them based on my usage patterns.

• Monotone: Having to specify "." to mean the current working directory (otherwise, any command applies to the whole working copy).
• CVS: Too many to list. Avoid at all costs. (probably the permission handling, though).
• Subversion: Not distributed.
  • SVK: adding distribution to subversion feels clunky.
• Mercurial: It's a monotone clone - why, dear god, why?
• Bazaar: Really weird approach to networking (though that may be outdated).
• Git: Source code quality, but that's changing.

Answer 5

Subversion. Its branching support is horrible - that is actually why I prefer Mercurial these days; I don't develop stuff on an airplane, but I do need to branch.

Answer 6

In my last two jobs I have been required to use IBM's Rational ClearCase and counting the ways in which this deficient and frustrating package saps my will to live on a daily basis would take me at least a week. Off the top of my head my main complaints are:

1. No concept of a unit of work. If I check in ten changed files to fix a bug or add a feature there is no way of viewing those changes as a group ever again. Even if they have the same check in comments.
2. Dynamic views will occasionally disappear on a reboot. Without going into details this means that files that other applications may rely on have a less than 50% chance of being there still when you restart your machine.
3. If I check in code into my branch and then merge back into main it won't automatically check it into main with the same comment. This means that if I want well commented checkins on the main branch I'm constantly repeating myself.
4. Practically no integration with Visual Studio (apparently this is better in 7.1, but of course we haven't upgraded to that yet)
5. A rather fast and loose idea of UI consistency with some dialogs having buttons down the right hand side and some along the bottom. Also some windows that really need to be resizeable (contain long filenames) aren't.
6. Rarely (but often enough that this has happened at least once to everyone I've spoken to in both companies) ClearCase will decide to add a random character into the middle of XML files.
7. The fact that IBM change $4,600 per license for this, and people pay it.

There are literally dozens more niggles which drag my productivity away from me as I have to fight the tool, and there is a good chance that I will come back and edit this post as a way of venting my daily frustration with this.

Answer 7

Subversion is quite slow, lacks features like offline-commit, sometimes the commit fails and requires an update, and if you have to use the @ notation to peek into your repo it's impossibly hard to use.

Bazaar is quite ok, but is mostly unsupported (by sourceforge at least). Also, I prefer the subversion model of branching/tagging.

Answer 8

Subversion has two major drawbacks.

• The working copy is 2x the actual size of your software. When working with large media files and multiple branches, this can get unwieldy.
• Tagging and branching are simply copies of a trunk. This gets extremely annoying when mapping the repository directory structure to developer workspaces. I long for the traditional branching and tagging concepts.

All in all, it's a very respectable VCS compared to many of the alternatives.

Answer 9

A while back I was stuck with Serena Version Manager. It was awful. Our repository was pretty complex, and the number of promotion groups we had, and branches we had, and tags we had was so out of control that unless you knew exactly what you needed to do, good luck. Far more complicated than it ever needed to be.

Now we're using TFS (and at home I use Subversion), and I'm a happy developer.

Answer 10

Serena dimensions was very crashy. We used to restart the server every day and also on a need basis. Otherwise, it becomes very slow. I am not sure if this is an implementation issue or a product issue. Also you can refer to Eric Sink blog for lot more details about version control.

Answer 11

Subversion (Well, Tortoise SVN; I think it's more a client issue) occasionally gets confused and I have to spend a while copying stuff aside into a scratch folder, re-adding, cleaning up, and so forth so that I can get it to do a clean update/commit without complaining about lock files.

Answer 12

I'm currently a Mercurial user and I really like it. But it has one downside: if a revision tree is really branchy, it gets slow. A lot of that comes down to some of the design choices that were made, and in particular the fact that changes are always recorded with respect to the last change committed (rather than the parent change). But I'd still pick it over anything else.

For me now, a version control system has two sine qua non features: (1) the concept of changesets, so atomic changes stay atomic; and (2) easy branch merging without loss of information. Essentially all DVCSes have this; most other VCSes don't. (Perforce comes close, but it always bugs me that a branch merge does not preserve the sequence of changesets, and comments, from the branch.)

But if I'm in an interview and a potential employer tells me they use CVS, I will walk out of the interview. (Actually, this is a question I usually ask at the phone-interview level. You can tell a lot about a company by which version control system they use.)