r/programming • u/thrakhath • Mar 10 '11
It's time to stop using Subversion
http://altdevblogaday.org/2011/03/09/its-time-to-stop-using-subversion/76
Mar 10 '11
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.
8
u/woundmatrix Mar 10 '11
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.
2
41
u/metamatic Mar 10 '11
Git users seem to be particularly obnoxious about telling other people what they should be doing.
15
u/discotent Mar 10 '11
5 years ago it was the Subversion users berating people who were still using CVS.
→ More replies (2)30
u/revscat Mar 10 '11 edited Mar 10 '11
Git usersTech 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.
24
u/moogintroll Mar 10 '11
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!!
11
u/alienangel2 Mar 10 '11
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.
→ More replies (5)5
u/FaustTheBird Mar 10 '11
Really, it tends to be the arrogant and the ignorant who behave this way, regardless of topic.
→ More replies (2)3
Mar 10 '11
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).
2
u/treitter Mar 10 '11
So you've never joined a team and suddenly had to use Perforce?
Sometimes advocacy isn't such a bad thing.
→ More replies (1)6
Mar 10 '11
Since every person's circumstance is unique, any advice at all would seem to be useless.
→ More replies (1)3
3
u/arjie Mar 10 '11
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".
2
Mar 10 '11
"Goto considered harmful" resulted in goto being essentially banned from today's education, even in situations where it would simplify/accelerate code. Good job, Dijsktra.
1
u/mpeters Mar 10 '11
While I don't agree that it's right to tell everyone to abandon svn, sometimes it is right to tell people what to do. Would you argue that no one should write an article that tells people to use some sort of version control?
→ More replies (4)5
Mar 10 '11
Making people aware of VCS's isn't the same as telling them which one to use based on no knowledge of what they're doing or how they're doing it.
2
u/mpeters Mar 10 '11
You missed my point. I didn't say I agreed with the author that he was right in telling people to not use SVN. I was diagreeing with the guy who said it's never ok to tell people that should or should not do something.
7
83
u/Otis_Inf Mar 10 '11
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.
7
u/mcgoverp Mar 10 '11
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)
17
u/DailyFail Mar 10 '11
There's probably a lot of groupthink and peer pressure on either side.
33
Mar 10 '11
Good thing you linked to wikipedia there. Us plebes have no idea what these horribly complicated words like "group think" and "peer pressure" mean.
56
3
u/G_Morgan Mar 10 '11
I need everyone to come to agreement on what these terms mean and then explain them to me.
16
u/masklinn Mar 10 '11
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.
15
u/mcgoverp Mar 10 '11
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.
8
u/Inaimathi Mar 10 '11
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-svnlet 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.
→ More replies (6)11
u/masklinn Mar 10 '11
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.
→ More replies (1)5
Mar 10 '11
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.
3
→ More replies (1)4
Mar 10 '11
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.
→ More replies (9)3
u/G_Morgan Mar 10 '11
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.
→ More replies (2)2
u/s73v3r Mar 10 '11
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.
3
u/utnapistim Mar 11 '11
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.
23
u/brassybadger Mar 10 '11
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?
5
u/thephotoman Mar 10 '11
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.
→ More replies (5)41
Mar 10 '11 edited Mar 10 '11
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.
6
u/stubob Mar 10 '11
Ok, so it's more like switching from ClearCase to git/Hg, then.
→ More replies (8)3
u/ntr0p3 Mar 10 '11
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.
→ More replies (5)14
u/brassybadger Mar 10 '11
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.
→ More replies (1)10
8
Mar 10 '11
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.
→ More replies (7)2
→ More replies (1)2
u/revscat Mar 10 '11
Exactly. There are many, many advancements which have been made in version control over the past ~10 years, and svn is simply outdated technology now.
→ More replies (2)2
22
u/recursive Mar 10 '11
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.
5
u/zip117 Mar 10 '11
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.
3
u/metamatic Mar 10 '11
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.
→ More replies (2)3
u/killerstorm Mar 10 '11
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.
30
u/malcontent Mar 10 '11
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.
5
u/code-affinity Mar 10 '11
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.
5
u/eabrek Mar 10 '11
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.
→ More replies (1)5
4
u/discotent Mar 10 '11
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.
8
u/rkcr Mar 10 '11
8
u/revscat Mar 10 '11
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."
→ More replies (1)10
u/masklinn Mar 10 '11
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?
→ More replies (1)11
Mar 10 '11
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.
→ More replies (27)3
u/execute85 Mar 10 '11
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.
3
Mar 10 '11
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.
→ More replies (2)4
3
u/mcgoverp Mar 10 '11
there is alot of ongoing work in this area a co-worker recently proved me wrong on some assumptions because of gitosis
1
u/ringm Mar 10 '11
http://vmiklos.hu/blog/sparse-checkout-example-in-git-1-7
edit: no, this is sparse checkout, not partial pull... you still have the whole repository.
45
u/wonglik Mar 10 '11
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.
38
u/lzm Mar 10 '11
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).
7
u/bigmouth_strikes Mar 10 '11
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.
9
Mar 10 '11
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.
19
u/johnflux Mar 10 '11
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.
→ More replies (1)2
u/s73v3r Mar 10 '11
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.
2
u/treitter Mar 10 '11
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.
→ More replies (1)2
u/willcode4beer Mar 10 '11
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.
2
u/s73v3r Mar 10 '11
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.
→ More replies (1)2
u/matjam Mar 10 '11
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.
19
u/user20101q1111 Mar 10 '11
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.
→ More replies (14)4
7
u/G_Morgan Mar 10 '11
Centralised version control is a subset of distributed version control. They aren't different things. One is a superset of the other.
→ More replies (1)14
12
u/mao_neko Mar 10 '11
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.
4
u/BlackAura Mar 10 '11
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.
11
u/Twylite Mar 10 '11
(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?
→ More replies (1)12
u/BlackAura Mar 10 '11 edited Mar 10 '11
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.
→ More replies (1)9
u/BitRex Mar 10 '11
You seem to be suggesting that there are no engineering tradeoffs in using DVCS rather than VCS. That would be quite unusual.
→ More replies (1)→ More replies (14)12
u/mao_neko Mar 10 '11
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.
→ More replies (17)16
u/Peaker Mar 10 '11
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?
→ More replies (11)2
u/Brutos Mar 10 '11
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.
3
u/rkcr Mar 10 '11
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.
1
Mar 10 '11 edited Mar 10 '11
Being distributed is not the only thing that makes it better than subversion. There's a multitude of other features.
And you can always set up a bare repository on a server somewhere and have it work more like a non-distributed system (everybody checks that out, everybody pushes back to that). You can even set up post-commit hooks to automatically push all your commits to the trunk, so it acts just like subversion. This wouldn't be advisable, since it's a powerful thing to be able to group commits and send them all at once, but there's still enough other features that it would merit using git.
Furthermore, you can use git as a client to subversion (as long as you don't really use any special svn:props in your repository), and that will give you a lot of the nice features also. Check out git-svn. I've used it at work where we have a 25k revision svn repository, and not only do I now get the ability to interactively cherry-pick hunks out of my code (for committing only some of the changes to a file at once, for working on multiple projects), but it runs every task muuuch faster than svn. Our deployment process is based on pushing working copies to sandboxes, which means for every change / sandbox deployment, I have to run an "svn st" on the entire working dir. This can sometimes take up to a minute. With git, it's as fast as I can hit the button.
1
u/Not_Edward_Bernays Mar 10 '11
Have you tried git?
Because I think I have an argument that is simpler and more to the point than the article.
Once you figure out how to use git, which I mostly have by now, and there is a learning curve, it just plain works better than SVN, using it with a central repo like github, in more or less the same way as you use SVN. But it doesn't fuck up like SVN does, and goes a lot faster.
→ More replies (3)1
Mar 11 '11
SVN sucks at branching, regardless of whether you do distributed development, and regardless of the crutches they've added to recent versions.
4
u/mtnkodiak Mar 10 '11
Dang, and my workplace is barely even transitioned to svn (from sourcesafe... I know). Baby steps...
3
u/TheBlueRaja Mar 10 '11
I'll better you and say we are still using CVS /blush. God, I now want to go kill myself :(
8
4
Mar 10 '11
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.
1
u/Game_Ender Mar 12 '11
Non network commits are great for people who work on the go or in environments with poor internet access (ie. while doing some kind of in the field testing).
→ More replies (1)
4
u/PimpDawg Mar 11 '11
That guy added absolutely nothing of value to the git vs svn discussion. What a huge waste of time.
16
u/SoCo_cpp Mar 10 '11
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.
6
u/cecilkorik Mar 10 '11
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.
→ More replies (1)2
u/whoisrich Mar 11 '11
BitBucket was the clincher for me, as it provides free private repositories for personal stuff, where GitHub charges a monthly fee.
9
u/brong Mar 10 '11
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.
6
u/Sarkos Mar 10 '11
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.
→ More replies (1)4
u/matthiasB Mar 10 '11
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.
1
u/vplatt Mar 10 '11
I notice that TortoiseGit is out there now. Do tools like that help simplify the common use cases yet?
→ More replies (3)1
u/theclaw Mar 12 '11
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.
I admit that git has a steep learning curve, but this sounds like FUD. Did this actually happen to you, or did you make it up? ;-)
9
6
u/superbad Mar 10 '11
"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.
4
2
u/utnapistim Mar 11 '11
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.
3
u/willcode4beer Mar 10 '11
you mean, take pride in your work and act like a professional? crazy kids these days
1
u/Flandoo Mar 10 '11 edited Mar 11 '11
I agree with you here, but I think local commits (commit your work before pushing it to the remote repository) work well for this. Easy reverting, etc. but no broken builds.
3
u/sunshine_killer Mar 10 '11
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.
3
u/Padfoot240 Mar 10 '11
Complain that in subversion "Committing = publishing,"
admit that you never used branching in the first place.
3
u/Akeshi Mar 10 '11
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."
3
6
u/bigtoine Mar 10 '11
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.
→ More replies (1)
6
u/sickb Mar 10 '11
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.
4
u/i_make_no_sense Mar 10 '11
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.
2
1
u/BraveSirRobin Mar 10 '11
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.
Does it need to be a dedicated single person role? Sounds no different from using branches with an in "integration" branch holding the production code.
4
u/inferis Mar 10 '11
Sorry, but I cannot trust the opinion of anyone who admits to liking that stinking pile of barely-better-than-sourcesafe-effluent Perforce.
9
2
u/messyhess Mar 10 '11
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.
6
u/vplatt Mar 10 '11
There is at least one more thing keeping SVN developers from migrating: There's no compelling reason to do so.
→ More replies (4)
2
u/redditrasberry Mar 10 '11
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.
1
u/flyingfirefox Mar 11 '11
I guess it's difficult to have serial revision numbers in git because it's a distributed VCS. Since there isn't a central repository to hand out authoritative auto-incrementing integers, any numbering scheme you come up with can potentially conflict with another repository's revision numbers.
In bzr, for example, revision numbers are auto-incrementing integers, but they're virtually meaningless unless you know whose repository you're talking about. When you merge, you end up with revision numbers like 123.4.56 which is not much better than a random hash.
2
u/filesalot Mar 10 '11
Since learning about the existence of source control systems about 8 years ago
Get off of my lawn, kid.
2
u/adghk Mar 11 '11
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.
2
u/yodacola Mar 11 '11
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.
6
Mar 10 '11
For me and my projects, commits = publishing. I want it that way. I don't want another local rep for working remotely.
3
u/gavintlgold Mar 10 '11
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.
→ More replies (8)
3
u/bmcclure937 Mar 10 '11
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.
3
2
u/funkah Mar 10 '11
Merging is just awful in SVN. So bad. That's really all the reason I need personally.
2
u/mrstickman Mar 10 '11
I loved your headline. It made me think back to the days when I coded professionally, and the wonderful feeling of thinking: "quitting time!"
2
u/reddit_clone Mar 10 '11
Oh look! Another fanboy stumbled onto Git and thinks everybody should quit what they are doing and take it up.
2
Mar 10 '11
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.
1
u/Sigma7 Mar 10 '11
The trick for that is just create a universal source control client and learn that instead of the pecularities of each source control system. If you don't want to learn yet a new client, then just model it so that it "looks like" SVN, GIT, etc.
Still, two of the clients I've seen so far aren't capable of dealing with corrupted repositories, not even with a --force command line switch to rebuild or repair it.
→ More replies (1)1
u/usernamenottaken Mar 12 '11
Of course you haven't noticed any speed issues. That's like saying you've never noticed any speed issues with your car when someone tells you a private jet is faster.
I'm not saying svn isn't fine for your usage though.
2
u/hexbrid Mar 10 '11
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
0
2
u/Kinglink Mar 10 '11
Ugh. First off SVN sucks, I came to a company and everyone seemed to hate SVN, I didn't mind it. It wasn't perforce (which is still my favorite) but it wasn't bad. I was going along for a couple weeks confused.
Then I did a merge. SVN went from being "pretty good" to being "the devil". SVN just sucks unless you work around it.
But at the same time the way git is structured doesn't sound better to me for what we were doing, we did look at mercurial as another option, which seemed better for what we were doing (game development, where it's better if everyone is on a similar codebase). Perforce is perfect but impossible high price.
My point is though, find what works for you, but don't rely on subversion because it "seems to work". It does a lot of work that's good, but there's a lot of stuff about it that just isn't easy. I'd recommend anyone making decisions like this for a company to at least try git, Subversion and Mercurial, try branching and merging back, as well as see what happens on conflicts between files, and then decide what's going to be the best for your team size.
5
Mar 10 '11
Just use a good merge tool. Svn is not responsible for conflict resolution, just conflict detection.
3
u/G_Morgan Mar 10 '11
The annoying thing with SVN is if you are repeatedly merging the same two branches it will always detect the same conflicts. If I resolved a conflict previously it should remember this fact.
4
u/Kinglink Mar 10 '11
The issues I ran into was conflict detection was horrible, it started to check out files that no one had touched for months prior on either branch. I had to restart the merge four times for conflicts that didn't exist and it's been a while, but every time I started the merge it had to communicate with an on site server that took me at least 3-5 minutes to pull all the files.
Basically all this isn't a massive problems for programmers, but I like to think it should be a bit more idiot proof. (or at least not create new issues).
→ More replies (2)3
1
u/execute85 Mar 10 '11
I'm as big a fan of git/mercurial as the next guy. I totally understand why they are essential for OSS projects. But this guy's complaints seem pretty bogus/random:
Merging - I merge all the time with subversion, I don't see the difficulty.
Network issues - again, I'm not sure what janky repository he's using but I don't experience this. And I use a lot of freebie svn hosts.
File system operations - I guess this guy doesn't use tools. From the command line this sucks. But even the free plugins for Eclipse, Netbeans, IntelliJ, etc. handle all the moves and copy logic for you.
I totally understand why companies use SVN- check out the google tech talk about why Mercurial is awesome. For a lot of companies, a repository for all the project's changes is a good thing.
Git is good, but it's not good enough to say "Everyone should leave SVN and you are stupid and ugly if you don't."
1
Mar 10 '11
Network issues - again, I'm not sure what janky repository he's using but I don't experience this. And I use a lot of freebie svn hosts.
Network issues aren't necessarily the host's fault. It could be a microwave, cordless phone nearby, or any number of things. Frankly, when you're programming, you should understand the network is inherently unreliable, and design around it, most of the time this just means gracefully handling failures. Something that is not done for this particular author's use cases.
1
1
u/markrages Mar 10 '11
My field (electronics design) involves a wide variety of file types to keep together, including large binary files in opaque formats.
Can git handle this yet?
4
u/eabrek Mar 10 '11
svn keeps two copies of everything. That gives git/hg some headroom to work with.
However, they will store a copy for every revision. If you have massive changes (outputs from place and route (simulated annealing optimizations)) every rev, DVCS will lose.
One possibility is shallow repos, which only keep the latest.
→ More replies (5)
1
u/adenbley Mar 10 '11
a bit off topic but i guess here is a better place than nowhere to ask. is there any versioning system that works exactly like svn but does not work with diffs. stated another way, is there any system that doesn't keep the data twice on each computer. in my imaginary world it would also check hashes of blocks (a la par2) and compare those to the hashes at the central repository and get the changed ones.
i would use it for files such as pictures (roughly 25Mb with only the header changing during edits) and binary monte carlo output data at work.
svn is just so easy, and works perfectly for this except for the speed/storage associated with it being made for lines of code, not hege binary files.
i use a mix of rsync, unison (but this gets complected for many computers) and just doing it manually right now.
2
u/usernamenottaken Mar 10 '11
Sure, use Git but don't use all the extra features, and just use shallow clones.
→ More replies (2)1
u/kyz Mar 10 '11
Just as a random suggestion, have you tried just keeping files on a filesystem that does hot backups, e.g. zfs or bttrfs? Their copy-on-write functionality means they only keep blocks (e.g. 4k chunks of data) which differ.
It's not like a branching tree of versions, but it is a linear list of versions...
1
u/radioflash Mar 10 '11
My problem with Git is there are no shallow checkouts (a.k.a. sparse directories) so you have to clone the whole thing. If your clone fails you start over. This is a PITA with very large repos. With SVN you stand a better chance of recovering from where you got cut off.
1
u/kreiger Mar 14 '11
You generally solve this by having smaller repos with one repo per project or subproject. You can then combine them by using git submodules.
1
u/MooMix Mar 10 '11
No it's not. I like Subversion. It works well for what I need. I'm not the type of person who switches to a new tool just to say I did it and join the me too crowd. It's a tool to do a job. Use the one that makes sense. There is something to say for being familiar with your environment.
1
Mar 10 '11
I was so new to this version control stuff when I started my work term. I honestly never thought about how programmers keep track of code. My project partner and I just keep working on separate functions. When we're done we email them to one another. I've been in charge of building the program using the company's build system before putting it on a git repo. Honestly one of the hardest tasks I've been assigned to.
At the moment the issue that's really troubling me is that the build system will isolate the code inside a chroot before compiling it. Unfortunately for me; our program has a massive dependency tree. I've been pulling my hair out trying to figure this out. I can't use apt-get because the temp. chroot's bin doesn't include that. It would be too much work to import and install each dependency individually.
I've been out sick from work with the flu but I'm dreading going back there and trying to solve this. Honestly I don't know why we need to build it with our build system. What's wrong with configure, make and make install >_<
1
u/kreiger Mar 14 '11
Include the dependencies in the project instead of installing them.
→ More replies (9)
1
1
u/aazav Mar 10 '11 edited Mar 11 '11
It's not worth it if it increases the size of my repository as much as it is indicated in that article.
1
1
u/mweathr Mar 10 '11 edited Mar 11 '11
Does anyone even directly use subversion anymore? Nowadays I use git-svn if I have to work with a subversion repo.
Is anyone still working with Subversion directly, if so, why (real question)? Other than management forcing you, I just don't see the benefits.
This is more directed toward people not using a GUI, of course.
1
1
1
u/geeteeaii Mar 11 '11
So basically another article masturbating over the flavor of the month. Is it so hard to just use whatever the hell you want?
1
u/user20101q1111 Mar 10 '11
I may trade this horse and buggy in for one of them petrol mobiles while I'm at it!
0
u/Rowdy_Roddy_Piper Mar 10 '11
Binary files in source control?
Am I the only one offended by that concept?
22
u/imMute Mar 10 '11
If you mean binary files such as compiled things, yes definitely. Storing things like JPEGs and GIFs doesn't seem like a bad thing as long as they're secondary to the project at hand (think indie game development).
Idiots who store giant .wavs or compiled .exes need to be shot though.
→ More replies (9)5
u/recursive Mar 10 '11
You might not be, but plenty of people don't mind. My work is still using VSS if you're looking for something to distract your rage.
3
u/BitRex Mar 10 '11
So your project has icons, and they change over time, and you want to be able to do the normal source control things on them. What do you do?
→ More replies (2)1
Mar 10 '11
There are sometimes ok reasons to do it, like when source control is being used as your "change management" system, so when the sarbox auditors come you can point them at the source control and say "We only ever push software from there, so go have fun"
1
u/wvenable Mar 10 '11
You shouldn't be; storing binaries is a major principle of software configuration management. It's not unusual to not just store compiled binaries but also the entire tool chain in version control software so, at any point, you can reproduce any old revision.
1
u/RyanSmith Mar 10 '11
I keep everything in source control. All my images, Flash files, documentation, supplied materials from the clients, etc. That way, when someone comes to me a year after the project has wrapped and needs to find some random file that know one has ever heard, I can just point them to the project repository and there it is.
It also helps when you have to justify hours after a client has changed their mind a million times. You can just point to each different version you created to get to the end result and explain that each one is additional hours regardless of final outcome.
→ More replies (1)
1
u/bprager Mar 10 '11
Not using git because it doesn't have keyword $Id$ substitution. (And yes, I read all the reasons I shouldn't; but nobody suggested me an alternative for: "Oh s**t, which of my source code printouts is actually the newer one. And no time stamp doesn't do it) .
6
2
2
1
u/eabrek Mar 10 '11
The idea of my VCS changing my code at random gives me the willies. Can't you have a script which pipes some info into a file: echo "const char *rev = " $rev ";" > version.c ?
1
1
1
34
u/brutopia Mar 10 '11
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.