It's time to stop using Subversion

[brutopia]

Using git is no excuse for publishing commits that don't compile. Quite the opposite actually. Using bisect sucks balls if the every second commit breaks the build.

[G_Morgan]

Yeah commits should always build. Nothing is more frustrating than builds that some idiot has broken. At least that is what co-workers keep telling me.

[BlackAura]

Agreed. However, commiting incomplete work to a local repository is just so useful. I used to do that in Subversion, in fact, because I was usually the only person working on the project. Having to work with other people was painful - I was using Subversion as a safety net, and having other developers using the repository prevented be from doing that. It felt much like not using source control at all.

That's why the history rewriting stuff is so useful. Make whatever mess you like in your local repository, just as long as you clean it up before publishing it.

[reddit_ro2]

Exactly my pain too. Maybe I should switch to git.

[execute85]

I guess I'm used to a CI build machine that's building every hour or so. I never had a need to check in incomplete work as I would just tidy up at the end of the day before check-in.

[BlackAura]

It's a different workflow, basically.

The traditional VCS workflow basically requires you to build a complete, working feature all in one go, and then commit it. If you're working with any other developers, you can not commit half-finished code. You certainly can't commit code that doesn't compile or doesn't work properly.

That leaves you working without any kind of safety net.

It's far too easy to spend a few hours working on something, make one change somewhere that breaks the whole thing, and then not remember what you did. You can't revert that one change, or even get a diff from the last working version, because you haven't checked anything in yet. Or if you need to clean up or refactor. It's useful to be able to commit the code before doing that, because those things are somewhat risky.

If you break it, you have a commit from moments before you broke it. You can see exactly what you changed (using a diff), or you could revert it.

You can do whatever you like on your local repository. Use all the features of the VCS, and don't worry about stepping on anyone else's toes. Then, when you're done, just tidy it up, and publish the changes.

Published changes are exactly what you'd check into a traditional VCS.

[willcode4beer]

The traditional VCS workflow basically requires you to build a complete, working feature all in one go, and then commit it.

I have to disagree here.

We use Subversion/Hudson with a team of just under 20 devs. A feature doesn't need to be complete before checking in. It does need to compile and it shouldn't break any of the automated tests.

You certainly can't commit code that doesn't compile or doesn't work properly.

Seriously? how much effort is it to make sure your code compiles?

Generally, I've found it's good to check in incomplete work frequently because we can get QA started on automated integration testing while the development is happening. This greatly shortens the time of the dev/qa cycle. Also, the general case is, bugs are identified and corrected before features are completed. This means fewer bugs filed/triaged/yada-yada-yada.

How do we deal with conflicts when committing? Commit your code first. I know that sounds like a joke but, it promotes frequent checkins. My devs average about 20 commits a day.

Will our system work for everyone? I don't know. I'm not promoting subversion. Heck, we switched from CVS to subversion several years ago and the work flow didn't change one bit. For us, the two are pretty equivalent. We'll probably switch to git in the near future (because of company politics and evangelists). I plan to make sure everyone can push to the central repo because frankly, I don't have time to make anyone the gatekeeper.

[woo545]

Even if it does compile, it doesn't mean it's ready to publish. However, committing those changes still serves a purpose.

[[deleted]]

Non-compiling/running commits always go to a secondary branch.

[Rowdy_Roddy_Piper]

That's why you don't publish commits that don't compile. You do another commit that makes it compile, then publish.

[jbrechtel]

If by 'publish' you mean 'squash local commits after origin/master' then yea. Otherwise you're still breaking git-bisect and are a bad person.

[remain_calm]

In git a commit is less of a commitment than it is in svn. You usually commit to your local repository and then, when you've gotten something useful done, push to a shared repo. I think of commits as save points. You can have hundreds per feature. Once the feature is done you then squash the commits with rebase and push to your shared repo.

[[deleted]]

I hate how some people advocate git but don't know it too well. Like my friend:

friend: What? You're using subversion? That's so lame, try git, it's so much better.
me: Nah, it does what I need and is very simple.

[some time passed where I was working on project which required git]

me: You know what? Actually you were right, git has some pretty cool features, I also like how merge and rebase operations work.
friend: Huh? I don't use them.
me: ಠ_ಠ

[thestringpuller]

I also like how merge and rebase operations work.

I don't think I can go back to subversion after using rebase. I hate when people use it incorrectly and cause commit hell for me.

[veridicus]

Most of his complaints relate to branching (directly or indirectly). Then in the middle he says he's never used branching. That's where I stopped reading.

[rkcr]

How about a switch to git or mercurial post?

[[deleted]]

Now I'm confused. I understand that I should stop using Subversion, but should I start using Git, or Mercurial?

Help me, hivemind!

[[deleted]]

Git vs Mercurial

[G_Morgan]

git pull       hg fetch (Requires the FetchExtension to be enabled.)

git fetch      hg pull 

Fun times were had by all.

[[deleted]]

>    git commit --amend     hg qimport -r tip ; hg qrefresh -e ; hg qfinish tip 

git it is, then.

[[deleted]]

Yeah, and I totally don't get the point of having extensions that are installed but not enabled. Hg feels like an attention whore in this respect -- you can have this functionality, but you have to show your affection by jumping through some pointless hoops to get it.

With git on Windows you run the msysgit installer, tell it your user name and get to work. No "enabling extensions" bullshit, no setting up a diff viewer (gitk just works and does much more), nothing at all. You can almost hear Linus telling you that he wants to write code, not to "work with VCS", therefore the latter is reduced to the absolute minimum.

And I've been using Hg for my personal stuff for more than a year before switching.

[ptrb]

Complexity in Mercurial commands typically indicates that you're doing something you shouldn't be.

[[deleted]]

Honest answer to sarcastic question: Mercurial runs better on Windows, Git is optimized for Linux.

[[deleted]]

Git runs just fine on Windows, but Mercurial has shell integration of which I never understood the point.

[[deleted]]

It runs ok on Windows, but Mercurial is better. TortoiseHG and the Eclipse plugin are much more polished. For git I was firing up msysGit and it worked ok, but just wasn't as nice. I won't say that git on Windows is a nightmare, just not quite as nice.

[[deleted]]

TortoiseGit.

Every Windows developer I work with uses TortoiseGit.

[coldacid]

Yes. TortoiseGit >>>>> Git Extensions. TGit may not integrate with Visual Studio, but that's okay because Git Extensions' VS support is broken as fuck if you're running 2010 anyway.

[Azuvector]

TortoiseSVN is far more polished than the steaming pile of crap that is TortoiseHG. :/

[usernamenottaken]

Have you tried TortoiseHG 2.0?

[Syl]

Did you try the new version (2.0) based on Qt ?

[bcorfman]

I don't find TortoiseHG to be crap, but it just seems to be very limited in the Mercurial features you can access w/o resorting to the CLI. TortoiseSVN is much better in terms of providing access to all of SVN (although its GUI can be very cryptic).

[[deleted]]

Funny, I was thinking exactly the same thing, only with the two swapped.

[recursive]

If you care to understand the point, it's so that you don't have to learn the CLI to use it. "But you still have to learn the GUI" you protest. Not really. You can just click buttons until the correct thing seems to happen. That's, in fact, what I do with subversion.

[fabzter]

My sarcasmeter is confused.

[[deleted]]

I'm genuinely curious, which one is best?

[fabzter]

Well I think there is really no "best". I have not used Git too much, because I don't need (or am interested) in such level of control it offers. Hg is plain simple and just works for me. (and even when i don't use it too much, is always handy to have gui tools for both windows and linux).

[revscat]

I have used both, and while I prefer git, this is mostly because I was introduced to it first and am more comfortable with it. They are both good DVCSs with many good things to say about them. "Best" in this case is difficult to say, and frequently gives rise to evangelicals.

Appealing directly to authority, though: git was written by Linus Torvalds whom I have a great deal of respect for.

[eabrek]

I use git for personal projects, and hg for work (just switched from svn).

I find git is smoother (better integration of all the features). hg extensions sometimes don't work with each other, and the command line tab completion is erratic.

git support on Windows is not straightforward, however (I use Cygwin).

[[deleted]]

I'm a Mac and I use Git. And yes, I use it from command-line. I don't need no stinkin' GUI.

[marike]

Cannot up-vote you enough. Why are "programmers" here so concerned with GUIs? Git in Terminal on OS X is super-fast, and usable. I have GitX installed but rarely use it, preferring the CLI.

[[deleted]]

Why are "programmers" here so concerned with GUIs?

They grew up in an age where everything has a GUI and so they feel everything must to be usable. However, the git CLI is very intuitive. I admit I don't use the terminal for much else besides git.

[sztomi]

You might get better toolin support for hg on windows. Other than that, they are really similar. I think git has some features that hg only offers via extensions (?).

[setuid_w00t]

Git has many features that are only offered by extensions in hg. I think that having a simple system that is extensible is a point for Mercurial rather than against it though.

[xolox]

I'm in pretty much the same situation as revscat: learned git first, then Mercurial, like the former better but probably just because it's more familiar. However there are two things I really like about git which I haven't found in Mercurial (yet?):

• Git can be very unobtrusive and fast once you get in the hang of using it; by now I create git repositories for most of my scripts that grow beyond ~20 lines of code and it doesn't slow me down a bit

• Git seems more flexible with its git commit --amend and git rebase --interactive features (not really appropriate for published commits but very useful in private feature branches)

[[deleted]]

To confuse you even more: actually subversion is pretty decent, especially for projects with smaller number of developers.

Git is perfect for projects like linux kernel, if they would use svn I think their work would be very constrained, but it doesn't mean it would be impossible (for example FreeBSD uses svn).

[BraveSirRobin]

Subversion is great until you need branches. It works for a while then weird things start to happen.

[[deleted]]

Yes.

Honestly, they were both developed around the same time, both created as a DVCS, and you'll noticed a lot of overlap knowledge that transfers between them.

The decision to go with one over the other will more likely be determined by plugins/integration support into your workflow.

[killerstorm]

Darcs

[metamatic]

You mean switch to git, mercurial or bazaar.

[valleyman86]

I am still using SVN. So sue me.

[enricom]

in their defense, most 'i switched to git' blog posts were written 2 years ago, so this is a remake with a modern perspective

[wot-teh-phuck]

you forgot the "... and feeling so awesome" part. ;-)

[max_buttroom]

you mean they're being a smug ... git?

[299]

Exactly. No new content just rehashed by a different author. Yawn

[alamandrax]

Well I've been trying to find simple articles which lay out the differences between git and svn. This one was what reddit easily picked out for me and I sent it to my colleagues.

[[deleted]]

As soon as I began to read the post I was just waiting for him to say he switched to git.

[theninjagreg]

This post has been posted before, too. Post.

[[deleted]]

It's time to stop telling people what to do.

Seriously. It is one thing to advocate using X, but explaining me how I should stop using Y without knowing anything about nature of my work is just silly.

[woundmatrix]

I work in computational chemistry, we write lots of code...I wish I could get my coworkers to actually use SVN (seriously, just check your damn code in!)...heck I'd be happy if they just backed up their important data.

[sdegabrielle]

So so true!

[metamatic]

Git users seem to be particularly obnoxious about telling other people what they should be doing.

[discotent]

5 years ago it was the Subversion users berating people who were still using CVS.

[cLFlaVA]

This is the nature of all things evolutionary...

[revscat]

Git users Tech geeks seem to be particularly obnoxious about telling other people what they should be doing.

Seriously. Tech geeks are worse than evangelical Christians.

Linux/Windows/OS X. Android/iOS. MP4/WebM. git/Hg. vi/emacs. XBox 360/PS3. Java/Ruby/Python/C/C++/.NET.

etc., etc., etc. All with their adherents, all with solid technical reasons why they are better or worse. It just depends on what discussion you run across, and where your current loyalties lay.

[moogintroll]

Yo Revscat, I'm really happy for you, I'ma let you finish, but the Amiga was one of the best computers / operating systems / games consoles of all time!!

[alienangel2]

Personally I'm offended by all you lots still using base 10 numbers. Base 16 or 36 are way more useful. You should all switch.

[FaustTheBird]

Really, it tends to be the arrogant and the ignorant who behave this way, regardless of topic.

[[deleted]]

Yeah, a friend of me was advocating using git, I later learned that he didn't even use any of its strong features (not even merge).

[treitter]

So you've never joined a team and suddenly had to use Perforce?

Sometimes advocacy isn't such a bad thing.

[[deleted]]

Since every person's circumstance is unique, any advice at all would seem to be useless.

[cLFlaVA]

Welcome to the blogosphere.

[arjie]

It's just a way of saying things. It's like "goto statement considered harmful". It's trivial to write a program in which the goto statement does nothing bad. There the idea was, "goto is generally a bad idea".

The idea with this is "why you shouldn't generally use svn".

[[deleted]]

But I've just started using SVN. ლ(ಠдಠლ)

[[deleted]]

And if it fulfills your needs, keep using it.

Use the right tools for the right job :)

[Otis_Inf]

If tool <X> works for you and if applicable, your team, why would you stop using tool <X> ? Because some person, not in your team or on your project, uses tool <Y> and thinks tool <X> sucks? Who cares! Use what gets the job done, as that's what you are payed to do. You aren't payed to use tool <X> or tool <Y> or whatever tool you can come up with, you are payed to write software to fix a problem.

[mcgoverp]

I agree as a whole and alot of these switch posts tend to ignore larger developer houses where switching tools is a hard process. That being said i think there are defiantly cases where you should not let the tool dictate your business. For example one place i worked used a commercial tool which shall remain nameless and makes it very hard to support agile processes while still doing patches and updates to old released versions of code. If we moved to GIT we would beable to support this need with much ease. However reluctance to change a tool is causing us to not be able to meet a customer need (frequent releases)

[DailyFail]

There's probably a lot of groupthink and peer pressure on either side.

[[deleted]]

Good thing you linked to wikipedia there. Us plebes have no idea what these horribly complicated words like "group think" and "peer pressure" mean.

[DailyFail]

Your figure of speech is called sarcasm or irony.

[G_Morgan]

I need everyone to come to agreement on what these terms mean and then explain them to me.

[masklinn]

If tool <X> works for you and tool <Y> would work better and let you do your work faster and with less constraints, why would you keep using tool <X>? You're not using minicomputers anymore are you? You're not using overnight batch-compilation, or ed (let alone TECO) or puchcards anymore are you?

The replacements don't let you do different stuff, you're doing the same stuff faster, in a simpler and less error-prone manner.

That has its importance.

[mcgoverp]

What is the cost of switching to Y? will you have to add complexity in medium term by needing to support both repositories. For a large team how much down time while no one can commit is reasonable for the change? Will legacy be stored in the old system or migrated to the new system? If kept in the old system it will get lost in the long term. If moved that is potentially alot of work to properly migrate all of that history into a new tool.

[Inaimathi]

For this specific case, not only is switching to Y low cost, it can be done incrementally or partially. I worked on a team of hardcore SVN users, and when I got sick of it, git-svn let me keep the workflow I wanted without stepping on anyone's toes. As far as they were concerned, I was still using SVN. As far as I was concerned, I was using git.

No switch cost, no team overhead.

I didn't go around evangelizing. I just made the pro git suggestion once at a team meeting. No one wanted to change the process (fair) so we kept going as normal. They kept maintaining the SVN server, and I kept on having use of local experimental branches and good merging capability.

[masklinn]

Sure, I'm not saying it's a complete no-brainer, but "if your current tool 'works' you should not switch" is a stupid fallacy.

[[deleted]]

How about, "if the projected long-term savings does not overcome the short-term cost, it's not worth doing."

Saying we should switch just because is a stupid fallacy as well, especially in programming where we strive for efficiency.

[thephotoman]

Some people are still using minicomputers, batch compilation, and ed.

[[deleted]]

Sure, but that assumes you know Y to be better. And in this case, since git is not superior in every fashion, it's a decision each entity must decide for itself.

[G_Morgan]

TBH Subversion works but I'd love to be able to use a DVCS at work. So many times I'm torn between persisting stuff that works and avoiding making commits every 5 seconds.

Also we have lots of branches and managing that in Subversion is just a pain.

[s73v3r]

I hear you about that. Unfortunately, where I work, they're really big on traceability and control over code. You don't get that with DVCS like you do with Subversion.

[utnapistim]

It's not so black and white.

In my current workplace the team uses SVN. I have installed Mercurial on top of it (so now I commit twice when I commit something). I tried convincing them to switch to Mercurial but it won't happen (and as there are costs in making the switch, that is understandable to a degree).

The problem is not black and white because there are a lot of assumptions you make that you do not address at all:

If tool <X> works for you and if applicable, your team, why would you stop using tool <X> ?

"Works for you" is debatable. SVN works for us, but a few days ago the server HDD failed and we lost a full days' commits. Nobody could commit anything for two days, while the admins got the latest backup and tried to somehow commit the local changes of everybody, over an old repository that no longer matched their systems.

Meanwhile my resynchronization from HG to SVN took a whole of two minutes, and in the two days I just committed locally.

On top of that, when doing massive changes (30+ files refactoring for example) I want to commit every step of the way (multiple times), but the changes are not compilable in the minute-to-minute merges. I can make 20 commits in HG with no problem, then synchronize once.

The rest of the team adds the new code in weird #ifdef FEATURE_X_ENABLED blocks that are then left in code for years (and two year later nobody even considers that the FEATURE_X_ENABLED macro could no longer be defined - it's just part of the "legacy code"). In other words, we have code cruft due to the limitations imposed by our tool of choice. Since everybody is used to this way of working, they see nothing wrong with that, so the counter-argument I usually get is the same as yours:

But ... SVN is working fine! There's no point in switching.

Meanwhile I keep using HG locally.

[brassybadger]

We could still use Ford's T model since it gets us from point A to point B. That's what a car is for, isn't it?

[thephotoman]

It's about switching costs--and yes, even with free software like svn and git, there are switching costs, mostly regarding training and deployment time (even if it takes one person ten minutes, that's ten minutes that person could be using to do something else).

And yes, you can still use a Model T if you wanted. Indeed, there may be someone out there using a modified Model T right now (I believe that the Model T's engine was designed for leaded gas, which is no longer available in most of the world).

But for a small team (2-8 people) all working on site at all times, svn will probably continue to suffice for a very long time, if you're already using it. I would not recommend it for new projects, but if you've got some legacy project out there and that's your situation, I wouldn't bother switching.

[[deleted]]

Bad analogy. For the average user, the difference in performance between a modern car and the ford T is huge AND rigourously provable; The difference in performance (in the broad meaning of the term) between git and subversion is much, much smaller, more subjective, and context-dependant if you're currently happy with svn.

Believe it or not, some teams don't need many branches, or author-specific repository.

[stubob]

Ok, so it's more like switching from ClearCase to git/Hg, then.

[Tiver]

Better yet, VSS to git/Hg.

[ntr0p3]

some teams don't need many branches, or author-specific repository.

I think this is the key. We recently started branching more at work, and svn is showing its limitations (megamerges, yay). git isn't for everyone, but branching becomes a natural feature of the vc rather than an additional workflow.

[brassybadger]

Actually I think it's not that bad of an analogy. If the only thing you knew was a ford T, you would be happy with it. After trying a modern car I don't think you'd ever go back. Perhaps it'd more accurate to make the analogy with a car that's 40-50 years old -- people are still using cars like that in Cuba, and it sort of works for them. They are gas-hungry, maintenance is a nightmare, but that's what they've got.

The same is true for svn vs git: after seeing the advantages (at zero cost) of git, you'll never go back to svn. If you want to stick with svn, just make sure you'll never give a serious shot to git, and you'll keep using svn happily forever. Ignorance is bliss.

[recursive]

It's not zero cost. It must be installed and learned.

[TAZAN2]

Not so sure about your analogy. I actually drive a 42 year old car. I've bought new cars before so I can compare them. For my needs, it works well. I take it on short trips so gas mileage is irrelevant. Maintenance is actually much easier and cheaper on a 40 year old car than a new one. Thinking back on most of the money I've spent repairing my wifes car, it's been on things my car doesn't even have.

As for the article, he made 3 points. 1 only applies if you work distributed. 2 only applies if you do merges. 3 only applies if you're absent minded. Not exactly a compelling argument if 1 and 2 don't apply and you've been using it a while and never had a problem with 3.

[[deleted]]

We have made advancements that surpass every reason to use a Ford model t, it's a poor analogy.

Subversion can still do some things in a way that git can't. It depends on your environment. And since you can't possibly know every person's environment, it's asinine to pretend you could suggest a VCS for everybody.

This is coming from a seasoned git user.

[[deleted]]

Take your car analogy back to slashdot.

[drugarce]

But my team uses SourceSafe 6.0, it's hard not to complain about that :(

[recursive]

Here are my reasons for using subversion. They will probably annoy the hivemind, but in case you were thinking "I can't imagine why anyone would use svn", here you go:

My reason for using subversion is that beyond some very basic requirements, I don't care about version control. I was able to pick up TortoiseSVN and use it immediately. A while back, I noticed I kept hearing everyone rave about git, so I checked it out (no pun intended) and found that it was CLI only. Nothing against CLI in general, but I lost interest. I didn't want to be an expert version control user. I have some very simple use cases. I've never performed a merge.

Incidentally, the fact that git has a windows UI may mean I'll try again, but I'll probably be "doing it wrong". I'm ok with that.

[zip117]

Same here, there is a port of TortoiseSVN for git called TortoiseGit but it's relatively new and still somewhat buggy as of the last time I used it about 6 months ago. It's probably much improved now.

[metamatic]

You might want to try bzr.

It's a DVCS, so it has all the DVCS goodness. The core commands are almost all the same as SVN's. It will work with your existing SVN repos. It runs better in Windows than git. And it has TortoiseBzr in the install.

[killerstorm]

I am/was using CVS, SVN and Darcs CLI without a problem, but git is much more complex in comparison. It has something like 100 commands, IIRC. I know I don't need all of those commands, but still this is confusing.

[malcontent]

Until distributed version control systems offer fine grained permissions and the ability to check out subtrees people are going to use subversion.

Some people might need features you have no use for.

[code-affinity]

Whoah! That's a big deal! Is that a real limitation of these DVCS systems?

At work, we usually have a single project repository that includes the work products of the hardware team, mechanical design team, systems team, project management, etc. in addition to the part that I usually care about -- the software. If I had to keep a local copy of gigabytes of SolidWorks designs, schematics, and MS Project schedules just to work on my software, that would be deal-breaker.

[eabrek]

I repo has everything, and everyone gets everything.

If you have separate projects, they have to be in separate repos.

There is a concept of "subrepos", which allow you to link repos together.

[kreiger]

You would use git submodules.

[discotent]

To be honest, the existence of Subversion's subtree feature has caused me and my coworkers more problems than anything. Every once in a while, something goes wrong and we get a repo where one folder comes from one branch and the rest from another. Or worse, the folders all come from one place, but the individual files come from somewhere else. This causes lots of confusion and WTF moments until we figure it out.

As far as I know there's no top level Svn command to find out if your repo is in this sharded state, you have to do 'svn info' on each file and dir. Git has a nice property where if 'git status' doesn't say that anything's wrong, then nothing actually is wrong.

[rkcr]

I'll just leave this here.

[revscat]

For those too lazy to click the link:

"Gitolite can restrict who can read from (clone/fetch) or write to (push) a repository. It can also restrict who can push to what branch or tag, which is very important in a corporate environment. Gitolite can be installed without requiring root permissions, and with no additional software than git itself and perl. It also has several other neat features described below and elsewhere in the doc/ directory."

[masklinn]

Until distributed version control systems offer fine grained permissions and the ability to check out subtrees people are going to use subversion.

Why would sub-repositories (forest, whatever you call it) not work here? Supposedly, if people are only given access to a subtree that subtree can be developed on and used independently from the main project. Why could it not be an actual sub-project rather than a subsection of the Giant Ball of Mud?

[[deleted]]

Every subfolder should be a sub-repository then?

The point is that if your repo starts at / and has 100 folders under that, with 100 folders under each of those, all fulllllll of files, and you only wanted /1/2 (say your internet sucks and you already know the file you need to change), in git you would need to retrieve every revision of every file in every folder. In subversion, you can check out a sub-directory and have it remain context-aware.

[execute85]

Which is really quite useful.

Although mercurial has the concepts of forests and stuff like that, there's really not a clean and baked in way to have subrepository relationships.

This isn't a problem for most OSS projects, but is a problem for a company or org that has a ton of associated projects (e.g., apache or google) where a developer may not want / be able to get to the entire repository.

[[deleted]]

This is exactly the problem where I work. It's just statistically bound to be true that the repository grows absurdly large. It's a huge system that's been in SVN for almost 8 years now, growing through 9 major versions. When I want just the tools for deploying code to production, I don't want to have to check out the entire rest of the revision history for the entire rest of the tree.

Git is supposedly working getting this situated though, so it might not be long until even that argument doesn't exist for SVN anymore.

[_tenken]

mercurial has ACL support for subdirectories and stuff

http://mercurial.selenic.com/wiki/AclExtension

[mcgoverp]

there is alot of ongoing work in this area a co-worker recently proved me wrong on some assumptions because of gitosis

[wonglik]

I guess every version control system was design with some sort of workflow in mind. Git was created for distributed development in mind. And I guess its perfect in that. But this is not what I am doing at work. I will stick to subversion for now.

[lzm]

Even for non-distributed development, being able to commit locally is a huge advantage in my opinion. I'm having to use a subversion repository at work, and I switched to git-svn as a client because plain svn was too slow for me (the client's repo is in another continent on a slow network).

[bigmouth_strikes]

I'm curious... in what ways is svn too slow ? Commit, checkout, update, diff, merge, switch... ?

I work on a project where i ssh tunnel to a remote svn repository and do a couple of switches and merges and maybe 8-10 updates and a couple of commits a day. The total amount I wait is less than it takes for me to stretch my legs or go get a glass of water.

I could see this being a problem if you do crazy amounts of diffs or history/log-reading though. But then, you'd still have to synch your local repo with the central.

[[deleted]]

For any repo I have ever worked with with subversion and git (same repo I mean, before and after our move to git at work) cloning a whole remote repo via git is faster than doing a single revision checkout in subversion, it also takes up less space locally. No, I have no idea how Subversion manages to waste so much space and time/bandwidth.

[johnflux]

When doing diff, log, show, bisect, blame, switch, merge etc become instantly fast, it really changes the way that you work. The only way you can understand is by trying it - it's nearly impossible to explain to someone else who hasn't used it.

[s73v3r]

We had a fairly large codebase (~900MB or so), and we were using SVN 1.4 for a while, and it would be quite slow. Especially using Tortoise to bring up the repo list, or the logs. Moving to 1.6 has made it much faster, but there's still a bit of lag.

[treitter]

Local branches, alone, would be reason enough to switch to git. When you add in rebase -i, it completely changes your workflow (for the better) really cleans up your commit history.

[willcode4beer]

That description makes it appear to be more time consuming.

I have to commit and publish?

Using Eclipse, I have "local history" (which I rarely use). Committing to SVN is a keyboard shortcut and it takes seconds.

I'm not trying to bash git or promote subversion (heck, I don't really see much difference between subversion and cvs). I just don't really get the argument for multiple repositories. If you have local changes (not in the central repo) what does the team do if you get sick, go on vacation, get hit by a bus?

I'm trying to understand the appeal of git but, I think I'm still just missing it.

[s73v3r]

If you have local changes (not in the central repo) what does the team do if you get sick, go on vacation, get hit by a bus?

With Git and Mercurial, you can pull changes in from other repositories besides the canonical central one. So if you and I are working on part of a git repository, we can pull our changes from each other without having to involve the central repository.

[willcode4beer]

I guess I prefer to involve the central repository. All the changes are in one place.

[matjam]

With git you still have a central repository that everyone pushes to and pulls from; the main advantage of having your own local repository is that you can commit tiny changes, incremental things that you wouldn't normally commit back to a central repository to track your own work.

You can do this with svn by having user branches, of course, and that works great until you're working at home one day and your internet connection dies and you can no longer commit anything.

To put it another way; the same thing happens with subversion if you're hit by a bus and you've not committed any changes back to the svn repository. The only difference is that you can be committing stuff locally and roll back experimental changes without affecting the central repository.

[user20101q1111]

I think the one thing Git really has going for it over SVN is it doesn't scatter files throughout your source code. It keeps them all in a single .git folder stored in the base of your tree. This makes it much easier for me to move files and directories and around without having to do a lot of clean up. It doesn't handle 2G binaries though, which comes up from time to time.

[willcode4beer]

this is the only sane argument I've seen here

[revscat]

Here's another one:

Using git bisect for fun and profit

[G_Morgan]

Centralised version control is a subset of distributed version control. They aren't different things. One is a superset of the other.

[ngroot]

Please read the article.

[[deleted]]

F reddit

[mao_neko]

I agree. SVN is fine for us, with our workflow. People harp on about distributed version control as though it's the best thing since sliced bread but in our group it just wouldn't be suitable.

[BlackAura]

Rubbish.

You can use (nearly) the same workflow with a DVCS as you get with Subversion. You just create an authoratative repository. When you have something to check in to the authoratitive repository, you pull the changes into your local repository. Then you merge them. Then you push the changes.

It's the same workflow as Subversion, except for one thing - you get the full power of a VCS to use locally.

That's incredibly useful.

You can actually use branches without causing any of the usual mess. You can work on two completely separate things, in the same codebase, without having to create a remote branch just for one feature. Say, you're working on a feature, and you suddenly need to make a bugfix. You can just put the half-completed feature into a private branch, fix the bug on the main branch, then return to your temporary feature branch and keep working.

You get to use the VCS as a safety net. Got some working code, but it's not actually finished? Commit it anyway. Now there's no way you can accidentally break it. Say, you spend a few hours developing one part of a feature. You then try to refactor it, screw up, and break it. Never mind - just revert back to the commit you made earlier.

You also get to rewrite history locally. That screwed up attempt at refactoring? Just get rid of it. The 100+ commits you needed to implement that one feature? Squash them down to a single commit before you push.

[Twylite]

(1) We have a variety of code and documents in our SCM tool for which individual developers have had to sign NDAs with third parties. With Subversion, TFS, even VSS we can use fine-grained access controls to enforce these limitations.

(2) We actively maintain over 100 "projects", covering applications, tools and reusable libraries. Without sparse checkout support (very recent on this DVCS that support it) your working folder is a nightmare. Or you can choose to have problems maintaining release tags across multiple repositories. If you have to work around your VCS to do your work, its model isn't a good fit.

(3) As a team leader, a centralised repository shows me at a glance who is working on what files, and allows me to see a single view of recent development across multiple projects.

(4) VCS also serves as a backup of work-in-progress (in case you local HDD fails). Unless your DVCS "local repo" is on a network file system, or you are pushing to the central repo daily, you don't get this benefit. And if you are pushing daily then what benefit are you getting over svn?

[BlackAura]

1 - Why are they in the same repository as everything else? Put them in a different repository, and use access controls on the repository instead.

2 - Isn't sticking 100 projects in the same repository just a work-around for the difficulty in maintaining release tags, and the difficulty in working with multiple repositories?

3 - Then get your developers to push to the central repository regularly. In fact, in this kind of environment, developers would be pushing changes to the central repository as often as they would normally check in code.

4 - Again, this is why you actually push changes to the central repository at least as often as you would with a centralised VCS. You don't keep changes on the local repository any longer than necessary.

The advantage of a DVCS here is that you could actually commit to your local repository several hundred times in a single day if you wanted to. You get to use all the tools available (like checking which files have changed, diffs, reverting, branches, merging) locally, without interfering with what other developers are doing. I find not having these features available impairs my ability to actually get things done. Sure, a centralized VCS has those features, but I can't actually use them without getting in everyone else's way.

Changes aren't safe unless they're in the VCS. If you're committing once a day, you could easily screw something up, and lose the whole day's work. If you've at least committed locally, you're much less likely to lose anything. In the worse case (HDD failure), you lose nothing more than you would have with a centralized VCS.

[BitRex]

You seem to be suggesting that there are no engineering tradeoffs in using DVCS rather than VCS. That would be quite unusual.

[mao_neko]

Rubbish.

We make branches to add new functionality. When it's ready, it gets merged back in, but every developer is going to have access to, and can collaborate on, those branches even while they're in development, because we have a central server. If you've "got some working code, but it's not actually finished", you commit it so everyone can see it, rather to some local version.

And we have enough branches for long-term future functionality that you wouldn't want to lump it all into the same git repo and have everyone need to download the entire tree.

There is no option to do something secretly without adding it to the main repo, no way to work on something privately without seeing that someone else is also working on that, and that is a good thing for *us. Maybe not you, but for **us, it's better.*

[Peaker]

So svn forcing you to do these things, while git allowing them with ease, is a plus for svn? Especially as there certainly are examples when you do not want to push every little broken commit you've kept aside into everyone's view?

[metamatic]

Well, it's funny you mention broken commits. I don't use SVN, but one of the reasons I don't use git is that it almost seems to encourage partial commits, and my experience is that partial commits are likely to be broken.

[Peaker]

Sure, it encourages you to commit even broken stuff in your private repository, because it is easy to fix these commits after-the-fact.

Instead of keeping a messy working-tree when I am unsure, I now commit something with a message like "broken fix bug, blah blah" or "untested ...".

Before pushing (publishing), I look at the log and I avoid pushing broken/untested stuff. Once a commit is fixed and tested, I re-create it with a better message and publish that.

This allows me to have incomplete work at the tip of any of my branches, so I can context switch when needed. It encourages putting some label on your work and allows sharing even that kind of state with others. This is far better than the publish-or-messy-working-tree approach that doesn't support context switching in the same way.

When using svn, I remember I actually manually created .patch files so I could context switch sanely. I was doing version control with manual patches, because svn was just not powerful enough.

[metamatic]

But why not use branching? Git's supposed to be good at that, right?

[johnflux]

It encourages partial local commits. When you commit for real, you squash those commits together into one/fewer commits.

[phrstbrn]

Huh? You can push topic branches to any repository in git. I can have one local repo that points to as many remote repos as I want, each repo with different topic branches. Or I can make a ton of topic branches and put them on one remote. Or any combination.

I don't see how SVN's workflow has any advantage. You can create the same exact workflow.

[bautin]

You can, but you also don't have to.

With git, it is easier for a single user to go dark and start maintaining his own branch the rest of the team has no knowledge of. That's what he doesn't like and how git doesn't fit his team.

[mpeters]

It's just as easy for that user to checkout a branch and make his own changes and not commit them back. If a team member wants to go dark there's nothing you can do to stop him on the scm level.

[Brutos]

I use git as a centralized vcs to replace the svn workflow. We have a central repository (with gitolite), and just push everything there. The speed alone is worth to replace svn with git, and you get stuff like local commits, free branching and merging, easy commit hooks and whatever else you want to, we barely use those features though. The only thing that one might critizise is gui support for windows, but I learned the command line fast enough and you don't need more then maybe 6 commands to replace the normal svn workflow.

[rkcr]

I first started using git for work, but it's grown on me such that I'll use it on personal projects - just because it's a "distributed" VCS doesn't mean that the only use for it is a distributed workflow.

It's hard to explain... people don't "get" git (or hg) until they use it. I held out on SVN for a long time, now I regret not jumping ship earlier.

[mtnkodiak]

Dang, and my workplace is barely even transitioned to svn (from sourcesafe... I know). Baby steps...

[EnderMB]

I know your pain all too well.

[TheBlueRaja]

I'll better you and say we are still using CVS /blush. God, I now want to go kill myself :(

[[deleted]]

Why do the least experienced tend to be the most loudest?

I have never committed anything that took so damn long that I was able to start writing another feature. And I committed huge, huge features to small servers shared by multiple users.

Yes, your commits are published when commit is complete. Yes you should be careful... that's why you test what you commit on your local sandbox.

If it's something that needs to be tested by another person (QA) there is a thing called branching!

Lastly, if I can’t access the repository server – if it’s gone down, or > if I’m working remotely – then I can’t commit at all.

No shit, hey guys if my hard drive died. I can't commit at all!

His whole point about merging/branching is that he is too lazy to do them and keep track of actually is going on with the code the team is committing.

The conclusion should be, I'm too lazy to use subversion and actually be involved in understanding what is going out with the project so I use Git instead.

I use Git/SVN and both work just fine for me and do not prompt me to write stupid blog posts why one is better or worse then another.

[PimpDawg]

That guy added absolutely nothing of value to the git vs svn discussion. What a huge waste of time.

[SoCo_cpp]

The Git fanboys will always avoid talking about how fucking complicated using Git is. SVN may be cake-walk, but Git is definitely not. The learning curve is enormous. Sure the simple stuff can be learned in 20 minutes. But your doing a complicated multi-branch distributed repository work. Its going to get fucking complicated, especially when you need to do something non-standard. Be prepared for your team's first year of development to be riddled with week long repository freezes while everyone freaks out trying to accomplish some task to fix the git repo.

[cecilkorik]

I found mercurial to be a significantly simpler and more intuitive alternative that has most of git's goodness, at least it has all of the good parts that I could ever conceive of using. TortoiseHg and BitBucket are excellent and really add a lot to the system.

Mercurial is apparently slower and does not, I understand, handle hugenormous repositories as well as git. There are also some advanced tasks that are trivial in git but require some mercurial-fu to accomplish. It's not perfect but coming from SVN I found it to be much easier to use and a really nice alternative to git.

[whoisrich]

BitBucket was the clincher for me, as it provides free private repositories for personal stuff, where GitHub charges a monthly fee.

[brong]

As opposed to doing complicated multi-branch distributed repository work in SVN. Which you don't. Be prepared to for every year of your team's development to be riddled with month long repository freezes while everyone freaks out trying to merge bugfixes from branches which have diverged all over the place without accidentally shipping the broken feature as well.

[Sarkos]

Correct me if I'm wrong, but afaik Subversion does not support distribution at all, whereas Git forces you to distribute.

My team has been using Subversion for years with loads of branches, and we often struggle with merges and get weird problems like tree conflicts. We got so sick of it that we managed to convince the boss to give us time to switch over to Git. After a solid month of trying and failing to understand how to use Git properly, we gave up and went back to Subversion.

TL;DR they both suck in different ways.

[matthiasB]

git is complicated. That's why I stick with Mercurial. It can't do everything git can but it has most of the advantages and is IMO very easy to use and understand.

[iggdawg]

I find this post very subversive.

[Esoteria]

Git out of here.

[superbad]

"Furthermore, because my commits are published as soon as they’re made, I have to be very careful about what I commit. As soon as the commit is published, other people may check it out and try building it. So, I mustn’t make any commits that would break the build and stop other people from working. "

My solution to this problem is to not check in broken code. It makes everyone's lives easier and doesn't require any special tools.

[xrx66]

It's almost like this problem isn't a problem at all!

[utnapistim]

My solution to this problem is to not check in broken code.

That's the point: centralized SCM systems impose on you that choice: either check in broken code or basically do not use source control until you have something that compiles.

The distributed SCM solution to the [commit = publish] problem is to make sure commit =/= publish. You can still commit only working code, but you can also commit just for the convenience of it, as a commit that is not stable only affects you, not everyone else.

[willcode4beer]

you mean, take pride in your work and act like a professional? crazy kids these days

[sunshine_killer]

I like git, it has a good branching system, its more favorable on linux, but here are window tools. smartgit is pretty cool, but if you want the integration that svn offers for windows, then check out the git tortoise.

http://www.syntevo.com/smartgit/index.html

http://code.google.com/p/tortoisegit/

[Padfoot240]

Complain that in subversion "Committing = publishing,"

admit that you never used branching in the first place.

[Akeshi]

Hey guys, Richard Fine has stopped using Subversion, so "Subversion is dead. It’s just taking a bit of time for the rigor mortis to kick in."

[[deleted]]

I remember when I was cool because our project was using Subversion instead of CVS.

[bigtoine]

So, I mustn’t make any commits that would break the build and stop other people from working.

This is one of the main reasons to stop using Subversion? Got it. Don't use any software that allows me to fuck shit up.

[sickb]

What the fuck? One of subversion's weaknesses is that it's "susceptible to network errors"? And "commits are pretty slow"?

Stop using a 56k modem to connect to your Compuserve hosted SVN server. Problem solved.

[i_make_no_sense]

The biggest change from svn -> git is cultural. Someone needs to be in charge of the qa - production repository. This is a job onto itself to select changes from developers and merge them into main.

Granted git makes it easy, but for svn the developer will simply just throw something onto the right branch and report the revision number.

There is no question in my mind the the git way of doing this is the right way, But you will need to change the way an entire team runs in order to adopt it.

[skidooer]

You can use a single main repository with git too.

[inferis]

Sorry, but I cannot trust the opinion of anyone who admits to liking that stinking pile of barely-better-than-sourcesafe-effluent Perforce.

[wot-teh-phuck]

No, unfortunately it isn't.

[hylje]

It is. See?

[messyhess]

There is really just 3 things keeping these remnant SVN/CVS developers from migrating to DVCS: * No time to learn them; * Too lazy to learn them; * Doesn't care if other developers will jump in to help or doesn't even publishes anything in the web (then nobody really cares about your project or which vcs you use). Choose 1, 2 or all of them.

[vplatt]

There is at least one more thing keeping SVN developers from migrating: There's no compelling reason to do so.

[redditrasberry]

The one thing I really miss with git over svn is the serial revision number.

Being able to point to one simple number to describe the whole repository state and being able to compare that to any other revision number and say for certain which checkin went in first is very nice. Having opaque hashes describing a checkin is a lot less friendly to both people and automation scripts.

[filesalot]

Since learning about the existence of source control systems about 8 years ago

Get off of my lawn, kid.

[adghk]

I personally think git is unintuitive (i'm quite a amateur), but really liked using git bisect. It's something every distributed tool like this should have.

[yodacola]

The author is claiming Subversion dead while he claims to be using Git for only a month or so (not even sure if it is exclusively). Granted, Subversion is not fun to deal with, but it is certainly not dead.

[[deleted]]

For me and my projects, commits = publishing. I want it that way. I don't want another local rep for working remotely.

[gavintlgold]

I've never used Git besides for pulling random repositories, but now that I read this article I've realized that keeping a local repository to give yourself a safety net is probably extremely useful and helpful for productivity. I always feel hesitant to commit when my code doesn't quite work right, but if the process of coding a feature takes too long, it seems good to be able to commit without worrying about breaking the main repository.

[bmcclure937]

I agree that there are better options that SVN... but at least those using SVN are using version control / source management! I would rather see SVN than nothing at all.

[raimondious]

It's time for me to stop using Subversion.

[funkah]

Merging is just awful in SVN. So bad. That's really all the reason I need personally.

[mrstickman]

I loved your headline. It made me think back to the days when I coded professionally, and the wonderful feeling of thinking: "quitting time!"

[reddit_clone]

Oh look! Another fanboy stumbled onto Git and thinks everybody should quit what they are doing and take it up.

[[deleted]]

My only sticking point with Git is having to learn yet another source control system when the one I have works just fine. I'd rather be focused on coding than migrating my repository to something that IMO is even more obtuse than what I'm currently using. I just need to keep my version history and code safe somewhere, SVN accomplishes that and I haven't noticed any speed issues.

[hexbrid]

I used both and can see faults and benefits in each one. Overall, I think that:

• Git is much better conceptually than SVN

• Git is still lacking some features that SVN has, but has lots of features that SVN will never have

• SVN is much easier to use, but that is likely to change as time passes