It’s time to stop using Subversion
altdevblogaday.org
altdevblogaday.org
I still use svn. For personal project, I have moved to hg. I use git occasionally. They all have its merits, and svn certainly didn't deserve "you should probably stop using it".
Reconfiguring build servers, rewriting documentation/wiki pages which have SVN Uris (or anything at all regarding existing source control) in them for projects that have existed 5-10 years as well as having an entire team learn a new source control tool is no task to be taken lightly.
I have 15 GB of svn repositories. I don't plan to migrate them. I use mercurial for new projects and I'm fine with old stuff to live in svn.
Just like I use more than one programming language, I use more than one OS, I use more than one database backend...
Currently that's git.
So now I'm looking back on 52 repositories. 16 in CVS, 14 in subversion and 22 in git (all of them counted only once) created over the last 10 years.
I did spend multiple hours though fixing non-fast-forwarded merges, accidentally created merges after pulling, incorrect author names and one accidental force-push.
All of these I could have prevented using policy on the server, but I would still have had to help explaining the underlying issues in order to a) get the broken commit in and b) make sure it doesn't happen again. Explaining takes much longer than just fixing.
The problem isn't technical. It's human.
The more employees/team members you have, the more complicated it will become to put all on the same boat. My experience above comes from a team with 4 people of which two were already git users (one of them was me).
I don't want to think what this migration would have meant if we were 10 or even 100 people.
That is a poisonous meme which should be fought tooth and nail. It basically follows the structure of the fallacy of grey¹: "every tool has qualities, therefore they're all fine".
It doesn't account for the fact that some tools dominate others. Meaning, they are demonstrably better in every way for every foreseeable usage. But we tend to cling to our old ways, instead of just saying "oops"² in exchange for new powers. We sometimes even actively try to deny others the very powers we refused to take.
Here, you were very close to make that mistake about svn vs Git/Hg/Darcs. Git doesn't dominates svn yet, but I'm sure it will. Then, subversion will deserve "you should stop using it".
But most often, this mistake is made with programming languages (it's a variation on the blub paradox). And the effects are far worse there.
I said in my comment I agree with the post in that git is "better" than svn. But svn is not that bad that it deserves a jihad of git users that can not stand not having world domination of their fav tool. That is ridiculous.
Like I also said, I didn't like the tone of the article which was "svn is dead and you should be moving along".
I also think the article has a point. I just don't think it was written in most productive (dare I say fair?) way.
> We sometimes even actively try to deny others the very powers we refused to take.
Huh? Who was that directed at?
Imagine you're on a small team developing closed source software. Like many people, you already have SVN, your team already knows SVN, it's already integrated into build system and you're using Trac for ticketing. Based just on that, I would absolutely keep using SVN instead of transitioning to Git. Perhaps you disagree, but I hope you'll at least concede that's a reasonable position.
So, a better example in the svn vs git matchup would be the handling of locks for binary files. Assuming of course you can't fix it yourself.
You come from the "ya, well..." camp it would seem? Supremely confident that your choices are the correct way to do things, but when someone points out a valid difference, your answer begins with "Ya, well...". I see this all the time from brash young superstars.
I didn't say that. I actually agree with that.
My other point was more general.
Are people who say that "every tool has qualities, therefore they're all fine" always trying to say that it does not matter what tool you use? If they are worth their salt, they will choose tool A if tool A works and is "better" than B, but will not assume B is inheritable inferior in all projects. The whole idea is to recognize the qualities of tools and asking yourself if you can really use them.
Suggesting that one tool is always better enables a mindset similar to that in manifest destiny ("[God told us] our culture is better than yours, so be like us").
I'm not saying you can not be "gray" and "wrong", but being gray is not unconditionally wrong and certainly does not deserve to be called "poison".
Now it doesn't mean we shouldn't be weary of sentences like "right tool for the job", "every tools has qualities". While they are correct generalities, they are often used to justify not to change habits: "We'll use C++. Don't say that, every tools have qualities. Besides, this is a big project. Languages are just tools, and you better use one that fits the job".
You could try to go against this trend: "But, because it's big doesn't mean we have to use C++. It doesn't mean you have to use only one language. It doesn't mean you have to squeeze every cycle out of your CPU. What about C + Lua? Simplicity by default, and speed where you need it".
But if you have to overcome fear of changing one's habits, this won't be enough.
Also, you seem to think that no tool dominates another. With that I disagree. Let's start with a contrived example: Lisp vs Blub, where Blub is Lisp without macros. I think it's reasonable to say that Lisp dominates Blub. A similar reasoning led me to think that ML dominates Java and C#[1] (at least if I pretend libraries don't exist and programmers know ML).
Sure, it hurts feelings to say to someone that his favourite tool is strictly worse than some other tool. But it doesn't make it wrong.
Now, I'll be in the corner using notepad and copying my file every time I make a major change. ;)
If you want your team to be more than a sum of the members (as opposed to stepping on each others' toes), you need decent communication tool.
Or you can dispose of communication by being a lone wolf.
Do you know how we communicated changes before git and other team tools? With our voices, markers, and boards. If your team steps on each other's toes, might that not be a problem with the team dynamics and not necessarily the tools themselves?
You are absolutely right about the way to propagate changes in ideas, prerequisites, protocols etc. etc.. Actually, I'm a frequent whiteboard user myself.
I should've made myself clear I was meaning the physical changes to the implementation files; in any case, something that is byproduct of information shared verbally.
The question is: Is a tool just 10% more efficient or does it introduce a whole new quality of working with it?
What do you do when your already delivered software has a bug that needs to be fixed urgently, but you already started to add new features that are not ready yet?
Using branches with svn is a thing just everyone is scared of (and rightly so), but with git, this has lost it's horror. You can confidently handle the above situation with git. That's a new quality.
Unless you want to work on a submarine, or have an organizational need for people to maintain private unpublished branches (eg, open source), I don't really see what advantages git has to offer over subversion in organizational (read: corporate) development.
And yes, it is great advantage that I can freely make a branch with the new feature that I just started working on, without having to summon a meeting to let everyone know that a new branch will be created, which is not intended to be used by anyone else even if it's visible to everyone.
As for working offline, my choice of the submarine example was intentional. 10 years ago I used cvsup (and later, svk) to work on the train and plane while using cvs and svn. That mode of working predates git quite a bit, but it's also much less useful nowadays -- Now I just use phone tethering and inflight wifi. I'd be working less efficiently without Internet resources at hand, so now that wireless technology has caught up, I don't have to.
Git is simply easier to use, and harder to shoot yourself in the foot with - at least when it comes to the basic flows. (Granted, you can blow your face off with git if you really try hard).
When branching in git is a simple git checkout -b newbranch away as opposed to svn copy http://repo.com/some/path/to/trunk http://repo.com/some/path/to/branches/somenewbranch - then what else is there to say, really?
Sure, svn is extremely easy to setup and use in small teams. But it is simply not geared towards modern development flows.
I appreciate tools that appreciate my time (and sanity) as a developer. And git does just that.
I don't know. I've trained a lot of developers with Subverison, Git, and Mercurial. Subversion is the one that I've honestly had the least trouble with, and Git the most. Heck, early on with git I had instances where the repo was so wedged I had to just torch .git and start over. I know more now and can get out of it, but with Subversion I've never* seen a user-facing command that causes Subversion to become mystically wedged and require a new repository for non-advanced users.
You can re-write branches locally and even on the server. It's to be used very rarely & carefully, but it has gotten the other team at my workplace out of a tight spot just two days ago.
More falsehoods. While it may be true that it's harder to corrupt the central repo (as opposed to your copy of it) [1], it's hard to lose work in Git even locally. Git is not fragile, nor complex. It has more features than SVN since it has more capabilities but most of the stuff just works.
It sounds to me like you don't really know much about Git. If you think you lost a change, you probably didn't. Unless a GC has happened the change is still in the repo, you just don't have any pointers to it. You just need to query the db for it (or if you know the hash code you can use that) and make a branch or tag to the revision when you find it.
Ironically, I find Git much more stable than SVN because in Git change sets are first class and cryptographically signed. I can always find the exact one I was previously working with if need be. Changes not being first class in SVN means you can't tell if you're looking the original change, the result of a merge, etc.
[1] It can be done pretty simply with branching though. If you share branches with each other it is possible to set up a situation where all further checkins for most users will create a large amount (depending on the previous branches) of fake conflicts.
[1]
Nothing worked anymore and the IDE managed only to spew out a dialog error saying `Nieprawid.'.
In git, cleaning the server up took just some command typing on developer machine. Could have been done from TortoiseGit, if they wanted to. The best thing is, the clean-up was `perfect' in that it left no traces of the fubar whatsoever. No faux merge left to trip up future merges by mis-placing the base version. Yay <3
Regardless, you can rollback changes in subversion without bungling future merges.
Yes and no. You can remove something from history if all holders of the copies agree with that. You can't forcefully remove anything from anybody's history if they don't actively cooperate.
So no malicious data loss possible, but an agreed-upon cleanup is.
Nb., in SVN only a central repo holds the full history. Should the admin remove some changeset, there's no way to check, or prove, that it ever was there. That is a (formal, legal etc) problem in certain situations. With Git, once you've fetched a changeset, it's there, all yours (till you explicitly remove it).
In SVN, should a malicious blackhat break in and add backdoor to code in a central repo, noone will notice. In Git, correctness and consistency is ensured courtesy of SHA1.
In Git and in SVN you can alter history. In Git, it's either `everybody agrees' or `somebody notices something went haywire because changeset chain doesn't match'. In SVN, it's `I trust the central repo with everything, fingers crossed'.
These features also make it very easy to make mistakes with your own local repository, and propagate those mistakes upstream (even if they can then be detected and resolved), which was the original poster's point, as I recall.
> In SVN, it's `I trust the central repo with everything, fingers crossed'.
In reality, this isn't an issue for organizations, and decentralization introduces a considerable amount of complexity that confuses most users. Businesses already rely on the correctness of centralized resources and have straight-forward processes to monitor and maintain them -- be it accounting data, a centralized CA, their corporate directory and payroll system, or SCM.
Ignoring the fact that this level of validation largely unnecessary -- if I were going to modify subversion to institute better validation of data, I would implement PKI signing of commits, not decentralization of the repository. Git has some support for this, but honestly this is not very high on the list of most organization's priorities, and largely only matters more for open source projects, if at all.
http://stackoverflow.com/questions/2475831/merging-hg-git-vs...
Better in practice, or better in theory? In practice, I personally haven't found that it makes a difference, and that the majority of cost in merging is in keeping abreast of functional differences, not in line-by-line conflict resolution.
YMMV, but I don't think it's as clear cut as you make it out to be.
This assumes that git has no significant practical drawbacks that might outweigh the constrained value of its merging support.
A bad car analogy: I never drive in the winter. I commute 1 hour each day to work. I have the choice between:
- A large SUV that gets 15 mpg but has traction control for handling icy winter roads and 16000 lbs of towing capacity
or
- A 30 mpg commuter car.
If we assume that subversion merging works fine (which, in large organizations, is my experience), then the next question is -- what feature(s), exactly warrants git's additional complexity? Why, in our organization, would we want to encourage people to create out-of-sight branches? What is the actual advantage to having individuals care about n-way merges?
I've never* seen a user-facing command that
causes Subversion to become mystically wedged
and require a new repository for non-advanced users.
And torching .git and starting over is easier than doing the same with SVN ;)
That's why I'm using git-svn; even when I have to use SVN.
In git, you can just push a clean branch on the server, if you take some caution. No elevated privileges needed. Actually, most of the time it won't be necessary, because the user will simply not push a wrong merge to the server. No need to clean up.
Actually once in a while I do torch whole repo (both .git and checked out files), but that's only when I was experimenting with something and didn't like the result. Cheap local cloning of Git repos makes that experimentation fast, easy & safe.
On the other hand, if I ever have to really, positively clean the repo to a known state, `git co -f $SOME_BRANCH' or `git co -f HEAD'; end of the story. Perhaps also remove the leftover untracked files, if I was cleaning merge abandoned in progress.
--
[1] as I described here: http://news.ycombinator.com/item?id=2310065
I'm trying to think if there's another piece of architecture our industry has both so universally embraced & discarded (hyperbole, I know) in the last decade.
Embraced and discarded? With a little hyperbole, and two decades of time scale, that's Win32. Startups used to do Win32 programs by default, now it's web. Of course big, hulkin' companies still do...
They're simply the last technology before a paradigm shift, and that's never a good position to be in.
Subversion is, imho, the best of centralized scm-s. There are many companies that, for some reason or other, will not switch to dvcs. It really doesn't matter that distributed model is better than centralized, some people will not switch over. And svn is great choice for them.
(Isn't version control mostly for text files?)
> If, while the upload's been happening, I've made more changes to my working copy...
(So you're uploading a large--presumably binary--file, and you're continuing to work on it while it's committing...)
> I have to carefully pick out my new changes and keep them separate from my old changes.
(Wait, what? In a binary file? Or did you commit the binary file and changes to smaller text files in the same changeset? If so, you should be committing them separately. Either you're making small commits to text files that commit almost instantly, or you're making large commits to binary files that you can't "pick out" changes from anyway. Gotta pick one.)
> As soon as the commit is published, other people may check it out and try building it...
> ... 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.
> ... but there are many reports [weasel words] of it being somewhat prone to error. If your mergeinfo property has been corrupted somehow, it might be extremely hard to spot...
I see a lot of inconclusive beating around the bush here. The author doesn't want to come out and say that any of these are concrete showstoppers because they are all, at worst, edge cases that experienced svn users mostly know how to deal with anyway. Every VCS has its own bugbears like these, git included.
I have been using subversion for years; I do all kinds of insane nonsense with private branches, merging and merge-tracking, large asset commits and all of the things this article uses for its doomsaying. I run into big problems maybe two or three times a year.
The writer suggests that git is better.
For some reason, even though I have read numerous manuals and guides about git, and have grilled git experts, and have regularly used git myself, and presumably understand how it works, I have to go on a farcical journey into its implementation details every time I do ANYTHING. I always end up in #git, or calling a more git-savvy friend. Everyone inevitably has a different answer that involves a lot of shrugging and "Oh, I guess this actually happened." This was the result even when all I did was follow the instructions at help.github.com/forking, TO THE LETTER.
Perhaps I am just a moron, and subversion is just VCS for morons. If so, I am too far gone to realize.
I don't say this as a git fanboy, just as a techie who hears "I had problems" and instantly wants to hear details so that I can evaluate the argument properly.
No. For long-life projects I snapshot entire build systems (toolsets, documentation, you name it) so that a precise image can be re-created later.
Years ago, in our 100+ coder company I kept finding copies of Microsoft's Developer CDs in CVS. Everything to set up a build machine was in there.
Furthermore, because developers sometimes didn't all have the same build environments, all of the intermediate builds were also checked in since you couldn't assume your machine would build exactly the same executable code as anyone else's machine.
CVS was definitely not built for this, but it worked. And if it works, and a programmer thinks it solves his problem, it will be used.
I discovered this because we kept getting problems with orphaned CVS locks, and people complaining of the slow checkins (CVS did the diff on the server, so upload the slow way over your ADSL line all those giant files that didn't change.) Which led to the day I typo'd a lock removal command and deleted all files with "rfl" in their name. Not a common sequence, unless your software deals with "overfly"s. Hurray for backups!
On the other hand, it's not entirely clear that you should include all that stuff inside a source control repository. This is something I've grappled with myself, in a number of contexts, and I don't have any great answers. In fact, I've usually just done what you do.
Still, given the time and incentives to really do it right, I think a better solution would involve keeping metadata versioned, and storing large binary files extra-repo. Within your repo, you'd have a file or a set of files that indicate that the tools you're using to build/test/deploy/etc are all contained within one or more uniquely identifiable tarballs. Your build process would have a way to extract the contents of those tarballs, if necessary.
Personally I hate command line interfaces and try to do everything I can in the windows Git GUI. I have to fall back on the command line a lot for cherry picking (when the GUI wont do it for some reason), stashing, rebasing (including various kinds of history rewrites), complex merging, conflict resolution, etc. and I find this easy to do with very little training (mainly just the Git pro online book). I would never even attempt the things you do with SVN because it would just be way too complex.
Well there's your problem, to quote certain TV personality.
Git supports several different workflows. Each one is valid. Some of them are incompatible with one another in some cases. Now everybody gives you instructions that make sense in his workflow. The instructions are correct, you apply them correctly and get a correct result.
Only that the result does not make sense in the (different, but valid as well) workflow that you use daily. That will happen sometimes if you don't make upfront a plan of what comes, or derives, from what, if you don't visualize what line of development merges into, or rebases onto, which.
But hey, presto! You can always git-reset your branch (read man first!, that's powertool and must be applied with care), or git-cherry-pick (fun and easy) some changesets and you are back on track.
Best thing is, if you somehow get into a tight corner, you can just remove this branch or repo and start afresh, if you haven't pushed to the server yet.
Push decoupled from commit is your ultimate parachute -- and comes with a backup parachute of local branching.
tl;dr: don't follow $RANDOM_INSTRUCTIONS; make a plan upfront and you'll know where you are at every step. And should that fail, deploy either parachute.
Now I like git but I can totally see why people don't use it (or in fact any DVCS). The central repository model is easily understood and implemented. The idea that there is no central "source of truth" is confusing--possibly even alarming--to an outsider.
Windows support problems for Git go beyond having no TortoiseSVN equivalent though. When I was setting this up I at first tried to get Git over SSH working with PuTTY and it a hair-pulling out experience. I eventually abandoned that effort in favour of Cygwin, which just worked.
TortoiseHg for Mercurial, on the other hand, is a pleasure to work with, especially the 2.0 release that just came out.
Also Git's CR/LF issues on Windows are a pain. The fact that I've never seen an issue with them on any other SCCS, and they seem to cause headaches with Git is another reason it'll have trouble catching on in a big way.
Also, it's not like SVN is suddenly bad or anything. I prefer GIT but I'm not tripping all over myself to switch over all of my existing projects.
I hear mercurial is working on support for these, but to my knowledge it's not something Git is overly concerned by.
I keep seeing statements like "If you're storing large binary files in version control you're doing it wrong", which leaves me wondering - what's the generally accepted approach for versioning artwork. I'm mainly thinking about source formats like PSD or fireworks PNGs.
Just because the user has a risk of doing that doesn't reflect badly on the tool, though. It's like saying that the big risk of a knife is that you'll cut yourself if you're not careful.
[1] Not a substitute for real backups of your repo!
Admittedly, this is a bigger problem in svn if you aren't using branches for work-in-progress.
Then again I usually felt safer if his work wasn't in source control anyway. I often thought it might be quicker to stay late and do the work myself from the start instead of staying late fixing his work as often as I needed to...
Unfortunatelly, not in your case. ;)
That was my previous place of employment: in-house perl scripts wrapped around RCS. Absolute nightmare.