Okay nerds, let's talk version control...

[MissileMike]

What do you use?

I currently rent a server that I run svn on, but I am tempted to just put all my projects in dropbox and upgrade to their 50 or 100 gig plan.  Has anyone tried this?  The main con I see is that they only save revisions for 30 days.  But the pro would be it's so cheap and convenient!

PS: Don't say you like perforce!

[keyboardlover]

I've been using svn for like the past 4 years and like it a lot. It's crazy easy to use and one of the best for merging/branching.

[prd]

I've been using svn for like the past 4 years and like it a lot. It's crazy easy to use and one of the best for merging/branching.

You should try Git or Mercurial.

[prd]

What do you use?

I currently rent a server that I run svn on, but I am tempted to just put all my projects in dropbox and upgrade to their 50 or 100 gig plan.  Has anyone tried this?  The main con I see is that they only save revisions for 30 days.  But the pro would be it's so cheap and convenient!

PS: Don't say you like perforce!

Have you tried Github?

[keyboardlover]

You should try Git or Mercurial.

De ce?

[aggiejy]

...I am tempted to just put all my projects in dropbox and upgrade to their 50 or 100 gig plan.  Has anyone tried this?  The main con I see is that they only save revisions for 30 days.  But the pro would be it's so cheap and convenient!...

I work out of my dropbox folder (iPhone dev), but I don't consider this version control.  Yes, it's technically uploading changes and I could rollback if it's recent enough.  But I wouldn't consider this as an option to replace svn.

Personally, I use 90% git, 10% svn.  I prefer git just for the fact that I like to commit locally more often than I want to push it up to the server.  (Makes rolling back to a particular point super easy.)  For hosting, I use github and springloops.  (Mostly springloops as it's a bit cheaper, and they offer BOTH SVN and GIT so I can have all of my projects in there. AND, they do FTP deployment to your servers if you're doing web work.)  I use Github mainly because other companies I do work with pay for it.  (Though, it is really nice.)

Of course, aside from the web interface, most hosts should be almost equal other than whatever limits they impose and how reliable/fast their servers are.

Git is certainly a lot more work to learn than SVN.  Takes a while to grok why to even bother.

Edit: I should also mention that if you work on multiple computers, your git repos saved in a dropbox folder work perfect across machines.  So for instance, I can be working on my Mac Pro, switch to my MacbookPro, and back... never worrying about the commit state or anything else.  If I set up (clone) a git repo on one, it works on the other.  (Aside from your SSH keys and such, but that's a one time setup.)  So I highly recommend Dropbox + git... at least for the type of work I do.

[prd]

De ce?

Decentralization, overall flexibility, ease of usage. There's a lot to talk about here. But that's my point. I'm also using SVN whenever I have to.

[keyboardlover]

Asa. Well, I only use it because my company does. I have no say in it.

We're moving to TFS soon though. I'm a little scared

[MissileMike]

I will give git a look- never tried it....

[theferenc]

I like subversion a lot, personally. It's mature, well understood, and has plugins for every real editor and IDE out there: xcode, textmate, visual studio, vi, and emacs included (do people actually do real work in other IDE/editors?). There's even a FUSE module in development, if you don't want to deal with commits by hand.

It's comfortable to old CVS users, but provides a much more robust feature set. Can be used with or without an explicit server. Can easily provide and encrypted channel over which to transfer state. Can be used easily with opaque binary files, and safely ignores files that contain only local state.

While git is better in the abstract, I find in day to day use, especially when working with multiple people on a project, svn is simply the better choice, especially if mixed platforms are an issue. For instance, we have commit hooks that modify line endings to server style, and checkout and update hooks that set them to host style. Of course, all of this can be done by git as well, but we have tested, deployed scripts for svn, and it works well for us.

I do know that outside of academia, the OSS world is mostly moving to git as an RCS. Within academia, I don't know of a single research group in CS or the sciences that doesn't use SVN. Most commercial houses I've worked with use either perforce or SVN, but I've seen other commercial systems in place, as well, though I don't recall what any of them are.

I've read good things about both git and mercurial. But you just can't go wrong with svn. It's proven, it works, and you don't have to learn a new system. If it ain't broke, don't fix it.

And avoid dropbox as an RCS. It just won't work reliably how you want it to.

[Superfluous Parentheses]

I use Git for everything. With github.com for my public code. Mercurial seems to work fine too but I don't want to mix up my work flow if I don't have to. Much better than SVN or the appallingly primitive CVS.

[theferenc]

I use Git for everything. With github.com for my public code. Mercurial seems to work fine too but I don't want to mix up my work flow if I don't have to. Much better than SVN or the appallingly primitive CVS.

Well, to be fair, CVS is from an earlier era. There is no reason CVS should ever be used, unless you absolutely can't use subversion. There is a reason most of the commands are the same, after all.

I guess subversion is just too heavily entrenched in my research group, but even thinking of moving away brings on a groan. Since I would also have to convince everyone else, after all. I think that's the big issue for me. I'm not the only one using the repo, and it has to be accessible to everyone in the group. Meaning we all have to agree on something. In our case, that's subversion.

Mike, I think that's a question that needs to be answered. Is this for your personal projects, or for a group working together? And if we sell you on something, will you then have to sell someone else on it, as well?

Also, from what I recall when I looked at it, migrating from subversion to git or mercurial with full revision history intact was simply not possible. Hopefully that's changed in the few years since last I looked. And looking now at the documentation, if you're working with a group, it appears that most of the advantages git has over svn disappear. Not all of them, but most of the useful ones, in my mind.

[daerid]

For all my personal projects, I use git. Any freelance work I do I also use git. At work right now we're using TFS, but it's a f**king joke because the people running don't even attach commit comments. There's no tracking of commit numbers, no assigning of work items or anything. I don't even think they know how to roll back a file to a previous version. All that it's being used for is code synchronization between devs. Makes me a bit nauseous. Good thing I'm leaving the professional development world behind, since most of the people I've worked with are morons.

Anyways, git rocks. I even use it as like a personal Time Machine-type backup system.

[keyboardlover]

Daerid - does tfs handle branching and merging well?

[bionicroach]

I'm playing around with Mercurial and like it pretty well so far.  Mercurial or Git + Dropbox is actually not a bad solution for doing version control and backup at the same time for personal development.  Here is a pretty good tutorial for DVCS noobs:

http://hginit.com/

I get the impression that most companies where software dev isn't the core business are very unlikely to adopt DVCS though.  In most "in-house" software situations, it seems like the decisions are unfortunately made by managers with little to no (or very outdated) software dev background, so newer technology is super slow to catch on, if ever.

[jpc]

CVS is made of Cheez Wiz. Anything else is fine by comparison.

I supported CVS for a large user base for a while. This was no fun at all. Users-- doing nothing wrong-- would uncover bugs in CVS that would leave their checkouts in a wedged state. We had some wrapper scripts over the top of CVS, and these grew complex over time as we added horrible workarounds for CVS bugs.

Later I ported the same wrappers to SVN. It was a breeze to support SVN: it's fast, stable, not buggy, and intuitive to users coming from CVS.

[jayfinger]

PS: Don't say you like perforce!

Ok, I wont.  But it's all I have used for a long time.  Certainly svn, mercurial, git, and many others did not even exist when my employer settled on that.  

What do the newer and more modern systems do better?  Enquiring minds want to know...

[alaricljs]

Certainly svn, mercurial, git, and many others did not even exist

That's the only positive I've ever heard about Perforce.

[Wibox]

git or bust

[HaveANiceDay]

Oh god, don't get me started on this. At work we use IBM Rational Synergy. You lucky ****s probably don't know about it.
Every time I use it, I get this urge to kick a puppy. Preferably one of IBM engineers pets. But I guess they didn't make the mess, just bought it from some Swedish ******* company named Telelogic.

Go on, make fun among yourselves and continue to use your open source version control systems. Go and use your plugins and tools. Fools! You don't know how good a life you've got!

[keyboardlover]

Lol...I used to use IBM rational clearcase and know exactly what you're talking about.

[panda]

Always used svn for everything. It just works. If it isn't broken, don't fix it =D.

[TexasFlood]

Oh god, don't get me started on this. At work we use IBM Rational Synergy. You lucky ****s probably don't know about it.
Every time I use it, I get this urge to kick a puppy. Preferably one of IBM engineers pets. But I guess they didn't make the mess, just bought it from some Swedish ******* company named Telelogic.

Go on, make fun among yourselves and continue to use your open source version control systems. Go and use your plugins and tools. Fools! You don't know how good a life you've got!

Lol...I used to use IBM rational clearcase and know exactly what you're talking about.

We still use clearcase, team concert, software architect, portfolio manager, etc.

[cbf123]

Most of the stuff at work is in ClearCase.  However, I'm a kernel/OS guy so most of my day-to-day work is done in git.

The main advantage of git over SVN is that it's truly distributed.  From the point of view of the repository, there is no "central" repository.  (You can arbitrarily declare one to be the main one if you wish, and this is what we do.)  However, if A and B have both synced from the same repository and done different work, A can pull in B's work directly rather than going through a central server.

For Linux kernel work this is awesome because I can track my own main server as well as the upstream git development, and if I need a bugfix that has gone in upstream I just do a "git cherry-pick" on that one change and I can apply it to our corporate version.

[TacticalCoder]

OK nerd, let's talk about it : a DVCS of course ; )

Mercurial here... But I may as well have gone the Git route. I used to use CVS and that was a world of pain, then moved to SVN and now it's Mercurial.

One caveat: you're a game designer right?  So you may have big binary files like graphics, sounds, texture, etc. and if these changes often, then "stock" DVCSes can be quite sucky.  So for example for Mercurial there's an extension (BFiles?) that makes working with big binary files more manageable.

But besides that caveat (for which there are solutions anyway), a DVCS is light-years ahead of non-decentralized version control system.  You have to use one to realize how great they are.  It takes some time to get use to it but it's really more than worth it.

We never thought about fixing bugs using what are now called "daggy fixes" because using a regular VCS such a workflow is just too painful.  Using a DVCS introducing a daggy fix can be a matter of seconds (read more about daggy fixes here: http://wiki.monotone.ca/DaggyFixes/ ).  This alone is a night and day approach to bug-fixing and we couldn't go back to the old way of doing that (and reproducing that workflow using a VCS is doable but sssooo ssllooww).

Then push'ing and pull'ing over SSH is very, very efficient.

Regarding backups we have on-site on-line backups, on-site off-line backups, off-site on-line backups (on rented dedicated servers and on DropBox) and off-site off-line backups (that's what safes at banks are for ; )  All the off-site backups are basically the entire DVCS repos encrypted (there's no DVCS allowing encryption out of the box so sadly our simplest option for private codebases that we don't want to be "in the clear" on dedicated servers we're renting, or on DropBox, is to backup the entire repos and then encrypt it and then upload the encrypted file).

DVCSes allow for many different possible workflows and they're way, way, faster than non-decentralized VCSes.  The regular VCS workflow can be re-created using DVCS but the inverse cannot.

Also DVCS are now quite big and do scale to the biggest codebases: the Linux codebase is using Git, the Java codebase is using Mercurial, etc.  There's a reason these gigantic codebases worked on by huge teams were migrated to DVCSes...

Now I do still admin a dedicated server (because of all the coders I'm the one with the more Un*x skills  that's basically hosting more SVN repos than Mercurial ones but that's only because several developers still haven't spent the time learning how DVCSes work.

It's always the same thing: people still on CVS or SVN will say that they don't see why they'd need Git or Mercurial yet you'll have a very hard time finding someone who did try both DVCSes and VCSes telling you that SVN is better.  Say for one developer who did try both SVN and Mercurial and that would prefer SVN, you'll find about a hundred that would prefer Mercurial.

That's my .2 commit on the issue and I won't enter in a VCS / DVCS war : )

[theferenc]

I still maintain it's a decision that needs to be made by the entire team.

As they say, the best version control system is the one that the team is willing to use.

[prd]

The team will use whatever is easier and already known to them, thus opposing progress.

I bet against a Round 3 Doubleshots set that Git/Mercurial is better than SVN.

[theferenc]

Better is quite difficult to define. They have more features, but both git and mercurial are distributed, svn is centralized, so they are addressing quite different problems. Personally, I find having a central repository is more practical, especially when you have a hard time getting your team to commit at all. If they had to both commit and push, that would basically never happen.

I see no particular problems with the distributed approach, though merging more than a few would likely be an exercise in pain, but I personally prefer the centralized approach, in a large part due to the nature of backups. It's just easier to keep a centralized repo (with branches if people want private space) properly backed up, and it's vastly easier to keep track of all the changes. In organizations which have strict accountability rules, distributed options are often not even worth considering, due to the lack of centralized access control.

[prd]

Better is quite difficult to define. They have more features, but both git and mercurial are distributed, svn is centralized, so they are addressing quite different problems. Personally, I find having a central repository is more practical, especially when you have a hard time getting your team to commit at all. If they had to both commit and push, that would basically never happen.

I see no particular problems with the distributed approach, though merging more than a few would likely be an exercise in pain, but I personally prefer the centralized approach, in a large part due to the nature of backups. It's just easier to keep a centralized repo (with branches if people want private space) properly backed up, and it's vastly easier to keep track of all the changes. In organizations which have strict accountability rules, distributed options are often not even worth considering, due to the lack of centralized access control.

Hehe. But not willing to commit and push ("push" as in "share", let's say) it's simply against team work.

"Better" is indeed harder to define. It surely depends on context. The context being that I want a round 3 doubleshots set.

[keyboardlover]

I would define better as two main things:
1. Features
2. Ease of use

[hashbaz]

Perforce at work, mercurial for personal projects.  I like both.  Yeah, OP, that's right.  Perforce is rad.

[prd]

I would define better as two main things:
1. Features
2. Ease of use

Ease of use weighs hard. And it awfully depends on ease of learning. This being said, I still want a round 3 doubleshots set.

[keyboardlover]

Ease of branching/merging is very important, especially in large projects. One of the reasons I love svn.

[prd]

Give me a round 3 doubleshots set and I will teach you how to love Git and Mercurial too.

[Soarer]

keyboardlover - You will not like TFS then! It's distinctly more annoying than SVN.

thereferenc - I'm not sure how pushing to a master repo is much different to committing to the only repo..?

I've used SourceUnsafe, TFS, CVS and SVN in work environments, but git only at home, and then only dabbling if I'm honest. The flexibility git offers (and presumably Hg as well) is certainly very nice from a developer's point of view.

[ch_123]

PS: Don't say you like perforce!

I have to use Perforce in work... Don't get me started.

[daerid]

Daerid - does tfs handle branching and merging well?

Sorry this took so long to respond to.

Branching? No idea. The guy at work who runs this thing doesn't even have a clue what a branch is in terms of VCS. But the merge tool is actually pretty good. It's simple, but it does the job well.

[daerid]

Ease of branching/merging is very important, especially in large projects. One of the reasons I love svn.

 
With git, branching/merging are so trivial there's absolutely ZERO reason not to. It's actually encouraged as a normal part of the workflow.

[theferenc]

Soarer, I meant more the multi-step aspect of git in terms of keeping a master copy.

[Soarer]

Still not sure I understand your objections to it... having a master repo means that backups and accountability refer to it, and you'd want a master repo anyway for making the build. I can see one potential drawback with the multi-step aspect, in that it might encourage developers to make a lot more changes locally before pushing them to the master. That would mean the master would be generally more out-of-date than is ideal, but on the upside, you probably get a more detailed history of the changes made, since a local commit does not need to worry about breaking the master's build. But, with good practise, you'd expect about the same amount of un-backed-up changes on developer's machines as in the centralised case.

[theferenc]

It's exactly as you said, in that devs often won't push all changes, but only sort of an aggregate change log up to the master. While working by yourself this is more than fine, when working with a group of devs, having to compare against multiple local mirrors to make sure you have the most current code is a PITA.

If people combined committing and pushing (via a commit hook, for instance), then this problem goes away. But then again, at that point, you just have SVN with different command names.

[EverythingIBM]

Lol...I used to use IBM rational clearcase and know exactly what you're talking about.

 
Awww come on, IBM is awesome sauce.

[TacticalCoder]

Regarding merging, the following question on SO is nicely formulated and the two most upvoted answers details very clearly why DAG-based VCSes do a better job at merging and why it's important:

http://stackoverflow.com/questions/2475831

[Soarer]

It's exactly as you said, in that devs often won't push all changes, but only sort of an aggregate change log up to the master. While working by yourself this is more than fine, when working with a group of devs, having to compare against multiple local mirrors to make sure you have the most current code is a PITA.

If people combined committing and pushing (via a commit hook, for instance), then this problem goes away. But then again, at that point, you just have SVN with different command names.

I'm not sure this is quite the problem you fear it might be... I imagine typical use by most devs would be pretty close to commit-push, certainly for small changes e.g. bug fixes. Even for medium sized changes, like adding a small feature, in many cases it would simply be something like commit-commit-commit-push. The 'current' code is what is pushed to the master repo, any local mirrors are only akin to someone's local copy of the code when using SVN.

Some devs might get fancy, trying things out on branches and merging only some of it back in to the active branch before pushing, but actually you don't want what they don't push in the master repo. Without the distributed control, those tests would often just be copies of the code, completely unmanaged in many cases - and that means no detailed commit log entries for potentially large changes.

Whilst you could have some subset of the team pushing changes to each other independantly of the master repo as they work on some mega feature, I suspect that scenario would be better served by creating a branch in the master repo. In either case though, once those changes are merged in there is a full history.

[TacticalCoder]

...While working by yourself this is more than fine, when working with a group of devs,...

Wait... Here you make it sound like working with lots of devs is an issue with DVCSes.

Take some of the biggest open source projects out there, no matter the metrics (say source line of codes for what it's worth):

Linux / Git
Mozilla / Mercurial
Xorg / Git
PostgreSQL / Git (late to the party, september 2010)
OpenJDK / Mercurial
OpenOffice / Mercurial (? don't remember)

These are some of the biggest team you can imagine on this planet and all these projects are using DVCSes.

Just wanted to mention these gigantic projects because your sentence made it sound like DVCSes where fine only as long as you were working on one-man or tiny team projects...

(btw I'll still ask you questions soon about your Linux / OS X / meta-shortcuts-for-window-manager-only-things only setup because I still need to configure all that "one day" : )

[theferenc]

I wasn't trying to say it was an issue in and of itself. It's simply a matter of getting the group to work together in the way that works for the group. Lots of folks I know just couldn't be sussed to deal with a two step commit process. And if you hook those two together, you lose most of the distributed advantages.

It's all a matter of how the group development process works. If people like to play with things, then commit the version that works, DVCSes have the advantage, since they can have local version control. Then again, having a "play" branch is quite common in most projects I'm currently involved with.

The real advantage of a DVCS is the lack of necessity in a network connection, and the multiple points of failure before you have a catastrophe. These days, that first is a non-issue. And if you don't have a robust back up policy in place for mission critical stuff, you deserve to lose it if your hardware fails. So it really comes down to personal and group preference. I prefer svn. You prefer git. They prefer mercurial. It's really all a moot point, in the end, as they all do basically the same things, in slightly different ways.

So try out several, and see which you like. I couldn't find anything in either git or mercurial to pull me away from svn, especially with all the maturity and scripting I have built up over the years. It just wouldn't pay for me to move. This is also why I still use tcsh, and prefer emacs to vi, kde to gnome, and the BSDs and Solaris to Linux. The alternatives aren't compelling enough to make me even consider switching. Some day, that might change. But it hasn't yet.

[Soarer]

Heh, I'm not trying to convince you to use git, I'm using this discussion to convince myself I haven't overlooked a potential issue when using git (or Hg)!

I have tried several, but not Hg yet. Apart from git, I've used them in a work environment. We currently have a project stored in SVN which has a long standing active branch, and usually when we merge stuff across to it, it needs manual intervention to get it right. Otherwise, it's just fine, but it's nowhere near as flexible as git. And that's key for me: even though I might only rarely make use of a small part of that flexibility, I'd like having it there just in case, as long as there's no significant downside.

[daerid]

For me, the ease of branching, making and tracking local changes, and rebasing your commit history make git the clear winner

[TacticalCoder]

For me, the ease of branching, making and tracking local changes, and rebasing your commit history make git the clear winner

I'm mostly using Mercurial but in addition to rebasing, another important point in favor of Git is the bigger user base.

For anyone interested, here's a long (1 hour 10 minutes) talk Linus Torvalds gave at Google on why he created Git and how Git works:

http://www.youtube.com/watch?v=4XpnKHJAok8

[HaveANiceDay]

Don't know how it's now, but git was famous for having terrible windows support through that msysGit project.
Maybe it's better now, but a year or so back, if you wanted good windows/multi platform support, Mercurial was the way to go.