6 ms·

Poll: Version Control

43 points by wtrk 18y ago

Which version control system are you using, right now, for your startup and/or for personal projects?

GuyE 18y ago
Subversion
apgwoz 18y ago
I adopted mercurial when git was "painful" to use. It seems as though this has changed, but I see no compelling reason to switch just because all the Rails kids think git's cool right now.
- jmtulloss 18y ago
  I love mercurial because it's so painless. It just works. Everywhere.
- KirinDave 18y ago
  Mercurial's metaphor for local branching is awkward. Git's metaphor is not, and most people go batty for it. That's a pretty good reason to change. I wouldn't use git if it didn't have cheap inline local branching. It is the Killer Feature.
  - apgwoz 18y ago
    > Mercurial's metaphor for local branching is awkward. That may be true (honestly, I don't know), but I haven't yet needed to maintain different branches of projects I'm working on and so it's a non-issue at this point. If at some point it becomes an issue, and I find Mercurial lacking, then of course I'll take a closer look at git, who probably does it more appropriately.
    - mleonhard 18y ago
      It's a good idea to make a branch for each release. Then you can easily look at the code that's in production and make patches.
  - silentbicycle 18y ago
    Mercurial also has cheap local branching, though to my understanding it is easier to close out branches that have been merged back in / abandoned on git. The mercurial developers are working on this, though.
- vito 18y ago
  I used mercurial briefly and found it to be much, much slower compared to git.
  - silentbicycle 18y ago
    Under what OS, hardware platform, filesystem, project size, etc.? Not knee-jerk arguing, genuinely curious. When I compared them on Windows and OpenBSD, I never had a speed difference of more than about 5% (not counting git db repacking), even with a project that had 40,000+ commits, 10+ very active branches, and about 2 GB of code + data.
    - vito 18y ago
      Admittedly it was probably either the environment or the remote server causing the problem. I was running it under Cygwin on Vista, and it was a fairly huge project. I was running git under the same environment for the same thing (with a different remote origin), and even then I noticed git was much more snappy. It's nowhere near an actual analysis, just my experience in my limited use (and probably influenced quite a bit by things that I've heard).
      - silentbicycle 18y ago
        Ok. (I was using an actual timer when I compared them.)
- jrockway 18y ago
  all the Rails kids think git's cool right now A stopped clock is right twice a day.
  - silentbicycle 18y ago
    It doesn't matter if they understand what's actually cool about it, of course. (http://news.ycombinator.com/item?id=327085 http://news.ycombinator.com/item?id=327085)
- MicahWedemeyer 18y ago
  I'm trying very hard to like git, being a Rails kid coming from the svn world. Still, besides the kickass merging, everything else seems ass-backwards. Remote work especially is bonkers. Push/pull? Easy. Add/Delete remote branch? Off to google for me...
there 18y ago
i'd like to know why people are using what they are. did you pick git because you just recently started using version control or was there really something you needed in it that made you switch? i've been using cvs for about 10 years now and have no reason to switch to anything else. it does what i need without any extra fluff, all my projects are in cvs, and the majority of the projects i contribute to use cvs.
- nihilocrat 18y ago
  Using bzr: our development is done in Python, so it's handy to be able to a) modify things if we need to and b) bundle bzr with our company's python install. It was the first distributed VCS I have used. I highly suggest it for personal or small projects, as it supports "dumb storage" and thus you can host a repo anywhere you have ftp or sftp access. It is also handy for working around annoying firewall restrictions where you can't really checkout code the way a centralized system does.
  - aston 18y ago
    Mercurial's also in Python. And I think in most benchmarks it comes out ahead of Bazaar. Might be worth a look.
- silentbicycle 18y ago
  Using mercurial -- it and git seem significantly better than the rest, but when I recently test-rode them both, mercurial felt like it worked better cross-platform, and the overall design felt cleaner. Git would be my second choice, and I'm sure github and the network effect will do a lot to popularize it. (I've read several blog posts in which people try git and are absolutely thrilled, but in almost all cases they were previously using CVS or SVN.) FWIW, I had been using Monotone for a while, but mercurial seems quite a bit simpler in day to day use.
- llimllib 18y ago
  git because I was able to introduce it gradually, due to its great svn integration. We just switched to it fully last week. I love DVCS because I get to keep the code on my computer version-controlled, and the power of branching, merging, and cherry-picking is awesome once you get used to it.
bayareaguy 18y ago
fossil
- graywh 18y ago
  The first thing I thought of was a version control system that only lets you make one version; then it's etched in stone for all eternity. So, maybe it's a bad choice for a name, but the system itself sounds interesting--it includes a wiki and bug tracking.
kingkongrevenge 18y ago
Multiple daily backups produced by rsync using hardlinks works well when revisions are too drastic and frequent to give a meaningful history. version control will just get in the way of one or two people drastically refactoring a young project.
- rcoder 18y ago
  I have to respectfully disagree here. Having super-lightweight branching and local commits has helped me greatly, even in the tumultuous early days of a new project. Basically, it gives me the freedom to create a branch, hack for a while, and then either pull the changes into the trunk or abandon them, while still keeping an easy "bookmark" in place (a.k.a. the branch itself) to go back and review later. Using rsync may offer a history of your code, but without any associated semantics, you're dependent on your own memory and grep to actually find out why a change was made. Making commits intentional, and associating them with a particular task, will greatly simplify your code archeology later. Rest assured, some day you will need to figure out why certain decisions were made, and your memory won't be complete (if it was even you who made the decision the first time). Furthermore, adding a ticketing system from day 1 really helps impose a useful type of discipline onto your process. Work to be done is described in a ticket, and the ticket identifier gets referenced in your commit messages. Much like basic version control discipline, having a record that associates change requests with units of work will help keep you sane down the road.
  - kingkongrevenge 18y ago
    > create a branch, hack for a while $ cp -R project testbranch > then either pull the changes into the trunk or abandon them diff or rm -rf. And none of the nuisance of explicitly telling the VC system when you're adding, deleting, and renaming files.
    - rcoder 18y ago
      I'm not arguing with the value of a filesystem as a general-purpose organizational tool. However, it's a strictly weaker tool in terms of structure and semantics than a proper VCS. Also, not only does using a raw filesystem put the burden on you to remember the associations between branches and versions, it also gives you zero support for merging once those branches are made. Git is pretty good about following renames, moves, and other changes to the underlying filesystem, while still maintaining a proper graph structure to relate revisions to each other. Fast network replication and mirroring is just another benefit, as is the ability to quickly merge changes from multiple branches. Finally, as another commenter has already suggested, it's really just about establishing good habits as part of your workflow early. It's much like testing: if you start out with a decent test suite, you're much more likely to maintain and use it than you are if you have to overlay testing onto an established project. Similarly, if you have full version history from day 1, things will be much easier further down the road.
bestes 18y ago
I use git because the low-level design is rock-solid and simple enough for me to understand. I also like distributed version control for the work alone and on a team aspect. This does not mean git is easy to use or that I'm even very good at it, BTW.
johnm 18y ago
Why do these polls get repeated so regularly? http://news.ycombinator.com/item?id=323041 http://news.ycombinator.com/item?id=323041
- graywh 18y ago
  Because not all of them make the front page? And even if it did, this person probably missed it. Really, is that so wrong?
- wtrk 18y ago
  Sorry! I follow HN primarily through the RSS feed and a lot of posts/threads never show up there. Before posting, I did Google for polls on the subject of version control and didn't turn up anything (oddly enough, this thread seems to be at the top of the results page): http://www.google.com/search?hl=en&q= http://www.google.com/search?hl=en&q="version+control"+poll+site:news.ycombinator.com Even if I had seen your poll, though, I probably would have posted anyway because I'm interested in getting a feel for how many people use some of the systems that are listed at top besides Git, Mercurial, and Subversion.
- ulysses 18y ago
  Also, that poll had much fewer choices. For that matter, this one doesn't have plain old RCS, which is what I use.
truebosko 18y ago
All projects right now use Subversion except one new project at home that I decided to try Git out with. All projects at work though use Subversion for now, but I am the only developer. (Just makes it easy to revert incase of issues as our system deals with a lot of numbers) I like Git .. it's very fast and simple to use :)
ph0rque 18y ago
Git for hacking projects, DropBox for personal files (which makes for interesting arrangements, since the git repos are in my personal files).
jcromartie 18y ago
I know from experience that git is superior, but I still use svn because it is the (modern) Lingua Franca of revision control. TortoiseSVN on Windows also gives it a definite advantage on that platform.
- silentbicycle 18y ago
  Tortoise is also available for mercurial. (http://tortoisehg.sourceforge.net/ http://tortoisehg.sourceforge.net/)
timtrueman 18y ago
Can anyone with experience with both SVN and Git comment on the pros/cons of branching and merging (this is something I do often in Perforce). Which would you use based on this one issue?
- llimllib 18y ago
  svn's complete lack of merge tracking is simply too painful to use. git will make you much happier.
  - rgilmour 18y ago
    svn as of 1.5.0 does support merge tracking. I must admit that when first looking into svn I was very surprised to find that it did not originally support it.
- silentbicycle 18y ago
  If branching and merging matters to you at all, switch to git or mercurial immediately. You won't look back.
- jrockway 18y ago
  I wrote a somewhat long article about Git merging: http://blog.jrock.us/article/Git%20merging%20by%20example.pod http://blog.jrock.us/article/Git%20merging%20by%20example.po...
jsmcgd 18y ago
This article talks about VCS as if they were airlines. You or may not find it helpful. Hope you do. http://changelog.complete.org/posts/698-If-Version-Control-Systems-were-Airlines.html http://changelog.complete.org/posts/698-If-Version-Control-S...
cookiecaper 18y ago
Git. It's extremely fast and featureful and I don't care about interoperability. Much faster than SVN or anyone else. Linus writes great software.
- jmtulloss 18y ago
  It's only a little bit faster than mercurial, and the size of the repository is larger.
  - notauser 18y ago
    I have a 250gb hard disk, and no spare minutes per day.
    - jmtulloss 18y ago
      The point of a large repository isn't whether or not you can store it. The point of a large repository is that it takes a long time to clone, and cloning is pretty damn important in a DVCS. I don't think anybody would suggest that size of repository matters for the number of bytes involved. There are obvious side effects of a large repository.
  - silentbicycle 18y ago
    Also, the project maintainers seem to place a very low priority on portability. People work on Windows, BSD, and OS X, too.
    - dzorz 18y ago
      Git works without any problems on OS X. On Windows it is getting better and better, and about BSD I wouldn't know.
    - cooldude127 18y ago
      there is a mingw port for windows. untested by me, but it looks credible. as for os x, that's all i use, and git works PAINLESSLY on it. i'm not sure where you got this information from.
callmeed 18y ago
Using Git, Mercurial, and SVN ... for diff projects
mcargian 18y ago
Using bzr. A few months ago when evaluating bzr, git, and mercurial, the features were similar between all three, but bazaar won in the ease of use category.
barryfandango 18y ago
Team Foundation Server.
tlrobinson 18y ago
Git itself is growing on me. GitHub is just awesome, especially for open source projects. (of course I say this just as GitHub goes down for the first extended period of time since I started using it) "git bisect run" is incredibly cool for tracking down when a bug was introduced: http://tlrobinson.net/blog/?p=51 http://tlrobinson.net/blog/?p=51
- silentbicycle 18y ago
  Mercurial also has bisect, FWIW.
rsobers 18y ago
Team Foundation Server.
wastedbrains 18y ago
Currently on SVN switching to git soon, just don't have the time at the moment. git looks like the best choice, and if I was starting anything new I would start with git now.
ced 18y ago
None. From where I stand, it seems like extra management duty, for marginal benefits.
- eru 18y ago
  Have you tried it? Version control makes you braver in deleting and rewriting.
  - ced 18y ago
    No. Whenever I go on a tangent, I just make a copy. I do AI, maybe that's the difference. Honestly, apart from utils.lisp, I wouldn't cry much if I suddenly lost all my files. Code is trivial, the important point is in the experience / insights. I'll try it some day for sure. It's just not that appealing. It was the same with Emacs.
- kalid 18y ago
  If you find your self with directories like "v1" "oldv1" "updateD!!!" you need version control :). Subversion has GUI clients integrated into file explorers so you don't even notice the overhead. I wrote more about it here, if you'd like convincing: http://betterexplained.com/articles/a-visual-guide-to-version-control/ http://betterexplained.com/articles/a-visual-guide-to-versio...
- joestrickler 18y ago
  It's not. I spent a week setting up and learning to checkout, update, add files, and commit. The only workflow change is an occasional trip to the shell to commit, but this is usually at the very tail of a session where it doesn't break flow anyway. Then (if you put in on a public server, of course) your work is accessible from anywhere. Run into a friend at Starbucks and want to show him the module you wrote today? Just get into the shell and checkout your repository. Not only that, it's a perfect record of your project. Occasionally I need to assess the status of the project vis-a-vis some point in the past (for myself when strategizing, for my boss when he needs a report, etc). Being able to look at the commit logs saves time and produces better reports (commit logs don't forget). So even if you use only the most basic features, you still get an immense benefit from using a VCS. And the hours it's saved me in trivial tasks made it well worth the week it took to hammer down.
noodle 18y ago
clearcase at work subversion for my personal/startup stuff
- ardit33 18y ago
  my god. poor you. I had to use clearcase a while ago, and it was painful.
  - noodle 18y ago
    actually, i've not found it to be difficult to use, just not as slick, clean and intuitive as other options. not the best, but not exactly bad, per se.
eru 18y ago
A friend and I agreed on Bazaar: Since he is working on Windows we could not use Git.
hapless 18y ago
Darcs' redeeming feature is that it's so, so, so easy to use. The documentation is clear and the system is simple. Distributed version control just doesn't get simpler. Unfortunately, it's not particularly portable and it's not particularly fast. The former I can blame on its dependence on ghc. The latter, I dare not.
toolong 18y ago
These all suck
Prrometheus 18y ago
Gmail, sadly.
mihasya 18y ago
I recently switched most of my stuff to git (granted I don't have that much source to throw around, so it was pretty easy) and absolutely love it.
brlewis 18y ago
RCS - I'm coding solo and RCS has essentially zero setup.
donniefitz2 18y ago
I know it's not kosher to mention here but you forgot Team Foundation Server.
schtog 18y ago
Is it worth learning a version control system for small personal projects, say 10 source-files and 5-10 different versions? I feel like I need something sometimes but most of the tools above seem a bit complicated and not very intuitive.
- asmosoinio 18y ago
  I use Subversion, and constantly check in my code. I love the feeling of control and permanence. 10 source files soon becomes 30, and 10 versions soon becomes 100 => Yes. How often do you do a bigger change, then realize you still need some pieces of the previous version? Version diff to the rescue!

43 points by wtrk 18y ago

Which version control system are you using, right now, for your startup and/or for personal projects?

GuyE 18y ago

Subversion

apgwoz 18y ago

I adopted mercurial when git was "painful" to use. It seems as though this has changed, but I see no compelling reason to switch just because all the Rails kids think git's cool right now.

jmtulloss 18y ago
I love mercurial because it's so painless. It just works. Everywhere.
KirinDave 18y ago
Mercurial's metaphor for local branching is awkward. Git's metaphor is not, and most people go batty for it. That's a pretty good reason to change. I wouldn't use git if it didn't have cheap inline local branching. It is the Killer Feature.
- apgwoz 18y ago
  > Mercurial's metaphor for local branching is awkward. That may be true (honestly, I don't know), but I haven't yet needed to maintain different branches of projects I'm working on and so it's a non-issue at this point. If at some point it becomes an issue, and I find Mercurial lacking, then of course I'll take a closer look at git, who probably does it more appropriately.
  - mleonhard 18y ago
    It's a good idea to make a branch for each release. Then you can easily look at the code that's in production and make patches.
- silentbicycle 18y ago
  Mercurial also has cheap local branching, though to my understanding it is easier to close out branches that have been merged back in / abandoned on git. The mercurial developers are working on this, though.
vito 18y ago
I used mercurial briefly and found it to be much, much slower compared to git.
- silentbicycle 18y ago
  Under what OS, hardware platform, filesystem, project size, etc.? Not knee-jerk arguing, genuinely curious. When I compared them on Windows and OpenBSD, I never had a speed difference of more than about 5% (not counting git db repacking), even with a project that had 40,000+ commits, 10+ very active branches, and about 2 GB of code + data.
  - vito 18y ago
    Admittedly it was probably either the environment or the remote server causing the problem. I was running it under Cygwin on Vista, and it was a fairly huge project. I was running git under the same environment for the same thing (with a different remote origin), and even then I noticed git was much more snappy. It's nowhere near an actual analysis, just my experience in my limited use (and probably influenced quite a bit by things that I've heard).
    - silentbicycle 18y ago
      Ok. (I was using an actual timer when I compared them.)
jrockway 18y ago
all the Rails kids think git's cool right now A stopped clock is right twice a day.
- silentbicycle 18y ago
  It doesn't matter if they understand what's actually cool about it, of course. (http://news.ycombinator.com/item?id=327085 http://news.ycombinator.com/item?id=327085)
MicahWedemeyer 18y ago
I'm trying very hard to like git, being a Rails kid coming from the svn world. Still, besides the kickass merging, everything else seems ass-backwards. Remote work especially is bonkers. Push/pull? Easy. Add/Delete remote branch? Off to google for me...

there 18y ago

i'd like to know why people are using what they are. did you pick git because you just recently started using version control or was there really something you needed in it that made you switch? i've been using cvs for about 10 years now and have no reason to switch to anything else. it does what i need without any extra fluff, all my projects are in cvs, and the majority of the projects i contribute to use cvs.

nihilocrat 18y ago
Using bzr: our development is done in Python, so it's handy to be able to a) modify things if we need to and b) bundle bzr with our company's python install. It was the first distributed VCS I have used. I highly suggest it for personal or small projects, as it supports "dumb storage" and thus you can host a repo anywhere you have ftp or sftp access. It is also handy for working around annoying firewall restrictions where you can't really checkout code the way a centralized system does.
- aston 18y ago
  Mercurial's also in Python. And I think in most benchmarks it comes out ahead of Bazaar. Might be worth a look.
silentbicycle 18y ago
Using mercurial -- it and git seem significantly better than the rest, but when I recently test-rode them both, mercurial felt like it worked better cross-platform, and the overall design felt cleaner. Git would be my second choice, and I'm sure github and the network effect will do a lot to popularize it. (I've read several blog posts in which people try git and are absolutely thrilled, but in almost all cases they were previously using CVS or SVN.) FWIW, I had been using Monotone for a while, but mercurial seems quite a bit simpler in day to day use.
llimllib 18y ago
git because I was able to introduce it gradually, due to its great svn integration. We just switched to it fully last week. I love DVCS because I get to keep the code on my computer version-controlled, and the power of branching, merging, and cherry-picking is awesome once you get used to it.

bayareaguy 18y ago

fossil

graywh 18y ago
The first thing I thought of was a version control system that only lets you make one version; then it's etched in stone for all eternity. So, maybe it's a bad choice for a name, but the system itself sounds interesting--it includes a wiki and bug tracking.

kingkongrevenge 18y ago

Multiple daily backups produced by rsync using hardlinks works well when revisions are too drastic and frequent to give a meaningful history. version control will just get in the way of one or two people drastically refactoring a young project.

rcoder 18y ago
I have to respectfully disagree here. Having super-lightweight branching and local commits has helped me greatly, even in the tumultuous early days of a new project. Basically, it gives me the freedom to create a branch, hack for a while, and then either pull the changes into the trunk or abandon them, while still keeping an easy "bookmark" in place (a.k.a. the branch itself) to go back and review later. Using rsync may offer a history of your code, but without any associated semantics, you're dependent on your own memory and grep to actually find out why a change was made. Making commits intentional, and associating them with a particular task, will greatly simplify your code archeology later. Rest assured, some day you will need to figure out why certain decisions were made, and your memory won't be complete (if it was even you who made the decision the first time). Furthermore, adding a ticketing system from day 1 really helps impose a useful type of discipline onto your process. Work to be done is described in a ticket, and the ticket identifier gets referenced in your commit messages. Much like basic version control discipline, having a record that associates change requests with units of work will help keep you sane down the road.
- kingkongrevenge 18y ago
  > create a branch, hack for a while $ cp -R project testbranch > then either pull the changes into the trunk or abandon them diff or rm -rf. And none of the nuisance of explicitly telling the VC system when you're adding, deleting, and renaming files.
  - rcoder 18y ago
    I'm not arguing with the value of a filesystem as a general-purpose organizational tool. However, it's a strictly weaker tool in terms of structure and semantics than a proper VCS. Also, not only does using a raw filesystem put the burden on you to remember the associations between branches and versions, it also gives you zero support for merging once those branches are made. Git is pretty good about following renames, moves, and other changes to the underlying filesystem, while still maintaining a proper graph structure to relate revisions to each other. Fast network replication and mirroring is just another benefit, as is the ability to quickly merge changes from multiple branches. Finally, as another commenter has already suggested, it's really just about establishing good habits as part of your workflow early. It's much like testing: if you start out with a decent test suite, you're much more likely to maintain and use it than you are if you have to overlay testing onto an established project. Similarly, if you have full version history from day 1, things will be much easier further down the road.

bestes 18y ago

I use git because the low-level design is rock-solid and simple enough for me to understand. I also like distributed version control for the work alone and on a team aspect. This does not mean git is easy to use or that I'm even very good at it, BTW.

johnm 18y ago

Why do these polls get repeated so regularly? http://news.ycombinator.com/item?id=323041 http://news.ycombinator.com/item?id=323041

graywh 18y ago
Because not all of them make the front page? And even if it did, this person probably missed it. Really, is that so wrong?
wtrk 18y ago
Sorry! I follow HN primarily through the RSS feed and a lot of posts/threads never show up there. Before posting, I did Google for polls on the subject of version control and didn't turn up anything (oddly enough, this thread seems to be at the top of the results page): http://www.google.com/search?hl=en&q= http://www.google.com/search?hl=en&q="version+control"+poll+site:news.ycombinator.com Even if I had seen your poll, though, I probably would have posted anyway because I'm interested in getting a feel for how many people use some of the systems that are listed at top besides Git, Mercurial, and Subversion.
ulysses 18y ago
Also, that poll had much fewer choices. For that matter, this one doesn't have plain old RCS, which is what I use.

truebosko 18y ago

All projects right now use Subversion except one new project at home that I decided to try Git out with. All projects at work though use Subversion for now, but I am the only developer. (Just makes it easy to revert incase of issues as our system deals with a lot of numbers) I like Git .. it's very fast and simple to use :)

ph0rque 18y ago

Git for hacking projects, DropBox for personal files (which makes for interesting arrangements, since the git repos are in my personal files).

jcromartie 18y ago

I know from experience that git is superior, but I still use svn because it is the (modern) Lingua Franca of revision control. TortoiseSVN on Windows also gives it a definite advantage on that platform.

silentbicycle 18y ago
Tortoise is also available for mercurial. (http://tortoisehg.sourceforge.net/ http://tortoisehg.sourceforge.net/)

timtrueman 18y ago

Can anyone with experience with both SVN and Git comment on the pros/cons of branching and merging (this is something I do often in Perforce). Which would you use based on this one issue?

llimllib 18y ago
svn's complete lack of merge tracking is simply too painful to use. git will make you much happier.
- rgilmour 18y ago
  svn as of 1.5.0 does support merge tracking. I must admit that when first looking into svn I was very surprised to find that it did not originally support it.
silentbicycle 18y ago
If branching and merging matters to you at all, switch to git or mercurial immediately. You won't look back.
jrockway 18y ago
I wrote a somewhat long article about Git merging: http://blog.jrock.us/article/Git%20merging%20by%20example.pod http://blog.jrock.us/article/Git%20merging%20by%20example.po...

jsmcgd 18y ago

This article talks about VCS as if they were airlines. You or may not find it helpful. Hope you do. http://changelog.complete.org/posts/698-If-Version-Control-Systems-were-Airlines.html http://changelog.complete.org/posts/698-If-Version-Control-S...

cookiecaper 18y ago

Git. It's extremely fast and featureful and I don't care about interoperability. Much faster than SVN or anyone else. Linus writes great software.

jmtulloss 18y ago
It's only a little bit faster than mercurial, and the size of the repository is larger.
- notauser 18y ago
  I have a 250gb hard disk, and no spare minutes per day.
  - jmtulloss 18y ago
    The point of a large repository isn't whether or not you can store it. The point of a large repository is that it takes a long time to clone, and cloning is pretty damn important in a DVCS. I don't think anybody would suggest that size of repository matters for the number of bytes involved. There are obvious side effects of a large repository.
- silentbicycle 18y ago
  Also, the project maintainers seem to place a very low priority on portability. People work on Windows, BSD, and OS X, too.
  - dzorz 18y ago
    Git works without any problems on OS X. On Windows it is getting better and better, and about BSD I wouldn't know.
  - cooldude127 18y ago
    there is a mingw port for windows. untested by me, but it looks credible. as for os x, that's all i use, and git works PAINLESSLY on it. i'm not sure where you got this information from.

callmeed 18y ago

Using Git, Mercurial, and SVN ... for diff projects

mcargian 18y ago

Using bzr. A few months ago when evaluating bzr, git, and mercurial, the features were similar between all three, but bazaar won in the ease of use category.

barryfandango 18y ago

Team Foundation Server.

tlrobinson 18y ago

Git itself is growing on me. GitHub is just awesome, especially for open source projects. (of course I say this just as GitHub goes down for the first extended period of time since I started using it) "git bisect run" is incredibly cool for tracking down when a bug was introduced: http://tlrobinson.net/blog/?p=51 http://tlrobinson.net/blog/?p=51

silentbicycle 18y ago
Mercurial also has bisect, FWIW.

rsobers 18y ago

Team Foundation Server.

wastedbrains 18y ago

Currently on SVN switching to git soon, just don't have the time at the moment. git looks like the best choice, and if I was starting anything new I would start with git now.

ced 18y ago

None. From where I stand, it seems like extra management duty, for marginal benefits.

eru 18y ago
Have you tried it? Version control makes you braver in deleting and rewriting.
- ced 18y ago
  No. Whenever I go on a tangent, I just make a copy. I do AI, maybe that's the difference. Honestly, apart from utils.lisp, I wouldn't cry much if I suddenly lost all my files. Code is trivial, the important point is in the experience / insights. I'll try it some day for sure. It's just not that appealing. It was the same with Emacs.
kalid 18y ago
If you find your self with directories like "v1" "oldv1" "updateD!!!" you need version control :). Subversion has GUI clients integrated into file explorers so you don't even notice the overhead. I wrote more about it here, if you'd like convincing: http://betterexplained.com/articles/a-visual-guide-to-version-control/ http://betterexplained.com/articles/a-visual-guide-to-versio...
joestrickler 18y ago
It's not. I spent a week setting up and learning to checkout, update, add files, and commit. The only workflow change is an occasional trip to the shell to commit, but this is usually at the very tail of a session where it doesn't break flow anyway. Then (if you put in on a public server, of course) your work is accessible from anywhere. Run into a friend at Starbucks and want to show him the module you wrote today? Just get into the shell and checkout your repository. Not only that, it's a perfect record of your project. Occasionally I need to assess the status of the project vis-a-vis some point in the past (for myself when strategizing, for my boss when he needs a report, etc). Being able to look at the commit logs saves time and produces better reports (commit logs don't forget). So even if you use only the most basic features, you still get an immense benefit from using a VCS. And the hours it's saved me in trivial tasks made it well worth the week it took to hammer down.

noodle 18y ago

clearcase at work subversion for my personal/startup stuff

ardit33 18y ago
my god. poor you. I had to use clearcase a while ago, and it was painful.
- noodle 18y ago
  actually, i've not found it to be difficult to use, just not as slick, clean and intuitive as other options. not the best, but not exactly bad, per se.

eru 18y ago

A friend and I agreed on Bazaar: Since he is working on Windows we could not use Git.

hapless 18y ago

Darcs' redeeming feature is that it's so, so, so easy to use. The documentation is clear and the system is simple. Distributed version control just doesn't get simpler. Unfortunately, it's not particularly portable and it's not particularly fast. The former I can blame on its dependence on ghc. The latter, I dare not.

toolong 18y ago

These all suck

Prrometheus 18y ago

Gmail, sadly.

mihasya 18y ago

I recently switched most of my stuff to git (granted I don't have that much source to throw around, so it was pretty easy) and absolutely love it.

brlewis 18y ago

RCS - I'm coding solo and RCS has essentially zero setup.

donniefitz2 18y ago

I know it's not kosher to mention here but you forgot Team Foundation Server.

schtog 18y ago

Is it worth learning a version control system for small personal projects, say 10 source-files and 5-10 different versions? I feel like I need something sometimes but most of the tools above seem a bit complicated and not very intuitive.

asmosoinio 18y ago
I use Subversion, and constantly check in my code. I love the feeling of control and permanence. 10 source files soon becomes 30, and 10 versions soon becomes 100 => Yes. How often do you do a bigger change, then realize you still need some pieces of the previous version? Version diff to the rescue!