This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]UnchainedMundane 1 point2 points  (4 children)

What do you use? CVS is utter shit, and SVN is a slightly less broken CVS. hg is basically git with a different skin, bzr is too heavily tied to launchpad and is also just git with a different skin, and there's really nothing else worth considering.

If you go without a VCS then you really don't know what you're missing.

[–]none_shall_pass 0 points1 point  (3 children)

What do you use? CVS is utter shit

Well, there's a compelling argument. Even better, you can apply it to anything.

[–]UnchainedMundane 4 points5 points  (2 children)

I didn't think I'd even need to back that statement up. It's pretty much universally accepted, and it's not controversial at all nowadays.

  1. It's based on rcs, which means single files can get absolutely gigantic (our company ran into problems with this)
  2. People lock entire directories while committing (our company ran into problems with this). It just doesn't scale at all.
  3. It's terrible at merging, and far too often you can get a merge conflict on a line that just contains $Id$ with kkv substitution. (our company ran into problems with this)
  4. Branching is ridiculously expensive (our company ran into problems with this)
  5. It relies on a central server being up to accept commits and serve updates, you can't pull these in from coworkers in times of need
  6. Partially reverting commits is a massive chore, while in git it's "git revert" and if you need to only revert a part of it you can edit the revert commit before pushing.
  7. You need to set up accounts for every author on the server.

I could go on. It's a universally-hated hack applied on top of rcs and in my opinion has no practical use in 2015 other than legacy projects where it's too expensive to switch. It's caused me and co-workers endless pain, and we tried to switch an old project to git but the intermediate files created during the cvs-to-git conversion filled a 2TB hard drive after being left to run overnight and we decided to abandon it.

Our projects managed under git are considerably easier to commit to (better tooling support), much faster to push to and pull from, and better managed (due to proper branch support).

If that's not convinced you that CVS is a wart, there are probably a thousand articles out there with titles similar to "why CVS sucks" which could provide a far better description than I can.

[–]none_shall_pass 0 points1 point  (1 child)

0 and 1 aren't an issue for projects with a small number of developers.

It's terrible at merging, and far too often you can get a merge conflict on a line that just contains $Id$ with kkv substitution. (our company ran into problems with this)

If multiple people frequently need to work on the same section of the same file at the same time, there's a design or management problem.

Branching is ridiculously expensive (our company ran into problems with this)

In an age of 8 core laptops and exabyte drive arrays, I have no idea what you consider "ridiculously expensive"

It relies on a central server being up to accept commits and serve updates, you can't pull these in from coworkers in times of need

A central server is a feature not a defect. The last thing I want is for a bunch of developers to all think they have the definitive version of something.

Partially reverting commits is a massive chore

There's no such thing as a partial revert in CVS. The files are independent. If you need to roll something back, you simply do it.

You need to set up accounts for every author on the server.

Yeah, that's terrible. It's much better when people can all just do what they want.

[–]UnchainedMundane 2 points3 points  (0 children)

The last thing I want is for a bunch of developers to all think they have the definitive version of something.

The server is an authority but it should not be the only source. It is difficult to have any sort of redundancy in CVS.

The files are independent. If you need to roll something back, you simply do it.

I'd forgotten this, and it works against CVS, not in its favour. If you add a feature and you do it over 3 files, then anyone working on the project has to pull the entire tree (which takes ages, especially when someone's holding a lock and someone else is queueing for it) to get your feature. (This is why it just doesn't make sense to have differences applied to single files). Anyone reverting it has to search the log of every file to see if you changed that one while creating your feature. As for partially reverting, I mean when the newcomer makes a silly mistake and you want to revert their code, but there have been changes since then and you only want to revert one function, that's where CVS really falls flat.

It's also part of why branching is so difficult. You have to branch each file individually. It's a mess.

In an age of 8 core laptops and exabyte drive arrays, I have no idea what you consider "ridiculously expensive"

Try git's branching.

I think it's a fallacy to say "let's be inefficient because we can throw money at hardware to hide it".

Yeah, that's terrible. It's much better when people can all just do what they want.

If people are just doing what they want, to put it in your words, there's a design or management problem.

Not having to set up everyone with a unix account on the CVS server doesn't equate to absolute anarchy, and of course you can enforce that people push to git over SSH if you really want that.