What was the name of that version control tool before CVS, RVCS? Back in 2007 I had heard one very big name hardware company using that for version control and planning to move to CVS as they thought the former was beginning to show its age.
Or you could talk to Joe down the hall. He has the 'gold' version of the source code on his desktop. Don't forget to send him your changes when you are done and he will integrate it to the current 'gold' version.
The company I'm working at actually moved to ClearCase a couple of years back. It's the most painful development tool that I have ever used and I pity any future victims of IBM's marketing skill who choose to adopt it.
I'm kinda annoyed that every once in a while, somebody has to come along dissing svn, prophesying its inevitable demise and glorifying git. Yes, git is "better" than svn, I agree. I like the message in general, but I don't like the tone of it.
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".
It is almost as if there is a law of geek nature that says 'For every evangelist there must be a troll...' It is hard to appreciate the useful content when combined with gratuitous attacks.
It seems to me that a lot of the evangelists of one source control tool over another fail to realize that for companies that -aren't- startups, migrating between tools is a lot of work.
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.
In my experience, going from SVN to Git has been as simple as doing git-svn clone and then pushing up to Github (or Assembla). Then again, I agree that there's a lot for the users to learn, so it's probably best done during a refactoring phase and you need at least one Git master to be available to answer any questions.
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.
You use words and phrases such as "poisonous meme", "should be fought tooth and nail", "demonstrably better in every way for every foreseeable usage", "dominates"... Strong words.
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.
Some of my words ("poisonous") strengthen my statements. Others ("demonstrably better") restrict them. I'm aware that the relative power of tools isn't a total order. For instance, I disagree with "git > svn". For now. Therefore, bashing svn and praising git specifically isn't a good idea. But distribution may well dominate centralization for version control in general. I think the article has a point there.
Like I said, in general, I agree with the message (of the article) which is in a nutshell: git is newer and uses a different paradigm than svn which helps in many ways.
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.
I'd love to read a post where someone decided SVN is superior for their purpose, and their stance is defensible. I can't think of any reasonable use cases.
I'm not personally a big SVN defender/apologist, but I'll bite.
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.
Of course transitions always cost something. For instance, C++ is the best when all your developers know C++ and have to extend a C++ code base. This examples are short term, and don't answer the question "is the new tool eventually better than the old one"? If so, consider switching costs. If not, don't even bother.
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.
ya, well, factors external to the merits of the two tools is irrelevant to the question I intended to pose. My question could have been worded better, sorry for the confusion. loup-vaillant's explanation is clearer. ;)
Who made you the authority of what is "better"? Decisions to use tools comes from context, and there is nothing wrong with choosing a tool that fits the job.
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".
First, I agree 100% with what you just wrote. To the letter, at least.
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.
Having just spent the last month converting our operation to Git here at work, I can tell you the main force in keeping Subversion around are Windows users who are used to TortoiseSVN. There still is no viable Git UI for Windows (or any other OS, really -- but Windows is especially immature) and the people who make decisions a) use Windows and b) "don't have time" to learn git on the command line.
That's exactly why we had to go with Mercurial instead of git. Their Windows integration is approaching SVN. Plus we were already using FogBugz. So, Kiln was a plus.
The Jetbrains IDEs actually have excellent Git integration if that suits your purposes, which basically means Java (as many PHP, Python and Ruby programmers are married to simple text editors, emacs, vi, etc).
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.
Actually, I think Jetbrains RubyMine is a great IDE for Ruby and Rails apps too, so it's not just for Java. I love the Git integration because I haven't found a good Git GUI for Ubuntu.
I tried it a few months ago. I created a new repo and tried to add a file. It gave me an error. So I tried a different way of adding a file. It crashed hard.
TortoiseHg for Mercurial, on the other hand, is a pleasure to work with, especially the 2.0 release that just came out.
After spending days helping people recover from fetch/rebase and merges gone bad, I advise people to stay away from TortoiseGit altogether. Also, TortoiseGit makes no attempt to let Git's simplicity shine through. Why show a dialog box with a huge number of options when all I have to do at the command line is type "git commit -m'Foo'"?
This is my big problem with Git. TortoiseSVN is extremely well done and fits nicely in my workflow. With Git it feels like a hack. W/o better tools support Git is probably dead on Windows and Mercurial win the Windows world.
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.
I had a coworker who was super resistant to switching to git because of the command line thing. I decided to give him a walkthrough in the hopes that I could answer any questions. You know what the problem turned out to be? He didn't know about tab-completion on the command line.
How about, no? The day you realize the tools you use are not the most important part of your function is the day you finally understand what it is you do. Yes, tools can make things easier, run more smoothly, or make you happy but... Can you do the same, if not better, job with alternate, less efficient tools? Yes. Tool elitism is no better than language elitism.
Now, I'll be in the corner using notepad and copying my file every time I make a major change. ;)
You are mistaking the tools you use for the tools that a team can use. That's Git: it lets teammates communicate changes in a straightforward, consistent manner, with little overhead. With a tool suite to review, pull en mass or cherry-pick the changes at will; with the defaults being the most practical choices most of the time.
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.
Just to play devil's advocate here, and definitely not disagreeing with you, but...
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?
The easier you make things for people the less likely they are to mess it up. We used to get around by horse and buggy but I think you'd agree that a change in tools has been a benefit that lets us do things we couldn't do before, wouldn't because it was too hard or tried to do but failed often from the same mistakes over and over.
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.
> Can you do the same, if not better, job with alternate, less efficient tools?
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.
I don't understand the branching mantra that I hear from git proponents. Subversion has had merge tracking since 1.5, and with it, branching and method is as painless as it can reasonably be.
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.
Well, in my case it's not a submarine, but a train.
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.
I don't follow. Isn't needing a meeting to create a branch an organizational problem, not a technical one?
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).
> 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).
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.
Perhaps you want to re-read on git-reset. You can always rewind history to some arbitrary point and re-stack operations, both en-mass and step by step
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.
Subversion is simple enough that while you can find ways to mess up your local working copy, it's much harder to destroy previous work (in your local branch or upstream) or otherwise make a mess. Git is a complex, fragile (in the wrong hands) VCS.
> it's much harder to destroy previous work (in your local branch or upstream) or otherwise make a mess
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.
Merging about 240 files from big-change-branch into the main branch and also merging a small, incremental development branch into main at the same moment is a tight spot whatever version control you use.
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
> Being able to disappear/discard history has significant downsides, too.
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'.
> 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.
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.
If someone says svn is easier it's because they don't do significant branching. Git and hg allow you to branch sanely. Subversion doesn't. Someone that doesn't get this hasn't learned much.
It's not a DAG. Since you know that subversion has merge tracking since 1.5 I'm going to assume you know what I mean. I don't have time or space in a comment to explain why this is so much better. For an example or two:
http://stackoverflow.com/questions/2613525/what-makes-mergin...
I don't have time or space in a comment to explain why this is so much better.
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.
Let's assume it isn't as clear cut as you say. That still leaves the question, why use an inferior tool? The argument that programmers are too dumb to reason about the distributed nature of a dvcs isn't a good argument to me. It took me one weekend with the pro git book for me to understand git well. That's a small price to pay for a superior tool.
... That still leaves the question, why use an inferior tool?
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 read your links. I also use subversion merging every day while maintaing feature and maintenance branches. It works fine and involves significantly less complexity than git.
I use git everyday. I don't know what this complexity is you speak of. It took me a weekend to learn git, and about the same for subversion, but git gives me more flexibility and power.
Flexibility and power come with complexity, and in his case, provide no practical benefits to most organizations. I use git regularly when interacting with open source projects, but don't see the value in it's added complexity and decentralization in corporate environments.
I was unclear above. My experiences getting git wedged came well before I ever taught git. I'm much handier with it now, and haven't wedged it in literally years. That said, I've found it easier to teach hg and svn since shooting one's foot off is much harder.
I've never* seen a user-facing command that
causes Subversion to become mystically wedged
and require a new repository for non-advanced users.
It happened to me 3 times already, with my local copy ending up in limbo - as weird stuff can happen when you're deleting a directory locally, with another dev having made changes to its files.
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.
Any very wrong merge[1] may leave the central repo in `working but contains nonsensical data' state. In SVN you can only commit a reverting changeset or you can alter the state of the server. The former leaves the merge around to trip up future merges; the later requires you to have admin access to the server and may break user's checkouts.
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.
Also: .gitignore is fundamentally saner than svn:ignore properties. You can commit it, or not. You can add to it locally without adding it into your next commit. You can make it ignore itself. It applies recursively.
As someone who got started in this field about 10 years ago, I find the mass-adoption of and then mass-exodus from subversion fascinating. I remember sitting in the audience for a talk by Greg Stein introducing subversion at ApacheCon ('02 maybe) and being wow'ed.
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.
The plans Subversion developers had were very promising; but the implementation wasn't that good and some non-obvious but handy features were missed. The enchanted users flocked to Subversion in hopes of it improving over time. The disillusioned users jump the ship once they learn of better alternatives.
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...
It's because 10 years ago there weren't really any distributed version control systems, and the original aim of Subversion was to fix everything that was horribly broken in CVS. They definitely succeded with that design goal, but since they're stuck in a centralized design, there's nothing they can do to move it to a distributed model, and it's not something that could have been foreseen 10 years ago.
They're simply the last technology before a paradigm shift, and that's never a good position to be in.
I think that's the best position (in case of svn) 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.
I agree that's what happened. But I'm still trying to think of whether there are any other cases of this in the last decade. There certainly have been other paradigm shifts. Yet i'm having a hard time thinking of anything which both gained significant prominence and then was left behind. Maybe OpenID?
The big risk I always see with git is that you start storing more and more work locally. This exposes you to the chance of hardware failure on a desktop pc. With svn, it would be easier for the hardware to be redundant and backed-up.
It's not hard to push topic branches to origin and delete them when they're done (although admittedly the syntax to delete a remote branch is a little strange).
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.
I fail to see your point. Every copy of a git repo is a full copy [1] - unlike a svn checkout. If you follow a centralized server model with git you have a copy on the server and every workstation it is checked out on. With svn, the full repo only exists on the server. Why couldn't you have a redundant, backed up central git server?
[1] Not a substitute for real backups of your repo!
Whenever people talk about git, they seem to talk about how you can have all of these working copies locally. My concern is the frequency with which code would be published to the centralized server and possible loss if all of the working copies were to disappear.
Admittedly, this is a bigger problem in svn if you aren't using branches for work-in-progress.
This and more of the same. One loony (who I now thankfully don't have to put up with any more) was always making changes without merging them back into source control, meaning things were marked as addressed in issues logs but there was no corresponding update in the source tree. Lucky we were using a checkout-and-lock model at the time (small team, with each of us generally working on distcint areas, so this didn't work out too inconvenient as it can do with larger teams) meaning we could see what files he had checked out. And sometimes he'd just edit local copies of files without checking them out/in at all, and often "lost" updates somehow (usually, I think, accidentally overwriting them with the source controlled versions he'd not updated). <Deity> alone knows how much confusion he could have caused with his own local repository. He might have worked for weeks without pushing to elsewhere then lose the whole local repo.
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...
Company I work at has everyone have their own clone server side, they then clone it locally, any changes they make get pushed back up to their clone on the server, from there they can ask for a merge request to merge it into mainline.
Aye, while he was still with us the chance to protect the central repository from any unverified changes from him was a very attractive idea. But given that he couldn't even file bug reports properly I'm not sure he would have coped with git.
Any time I take on a client project that uses SVN, I always use git-svn. Once you get used to working with git-flow and feature branches, you never go back.
> 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.
The article and your comment share the same deficiency: they don't deal with concrete problems (or at least when the article does it's about edge cases, as you point out). It's all very well for you to have decided that svn > git for your purposes, and I applaud you for having evaluated the two and chosen one based on relative merits. But in order to extrapolate from that to a general counter-argument to "git is better than subversion," you need to a) provide the details of the problems you had with git and b) explain how they are specimens of a general problem which SVN doesn't have.
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.
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!
I agree that reproducibility is very important, and it's worth going out of your way get it.
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.
You manage to do all these complex things with SVN and yet you can't manage Git? If this were any other site I would straight up call you out as lying. As it stands I would like to know exactly what it is you're doing that's so hard with Git.
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.
> (...) when all I did was follow the instructions at help.github.com/forking, TO THE LETTER.
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.
The large binary file thing keeps coming up again and again.
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.
PSD and PNG files are not usually counted as "large". When someone says "don't version large binary files", what they mean is "don't check in a DVD ISO of Fedora".
They may not suffer from the efficiency problems, but diffs and merges are still problematic. Is there any VCS tool designed to handle these sorts of things?
111 comments
[ 2.9 ms ] story [ 181 ms ] threadUnfortunatelly, not in your case. ;)
That was my previous place of employment: in-house perl scripts wrapped around RCS. Absolute nightmare.
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.
[1]: http://wiki.lesswrong.com/wiki/Fallacy_of_gray
[2]:http://wiki.lesswrong.com/wiki/Oops
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.
[1]: http://www.loup-vaillant.fr/articles/classes-suck
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.
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.
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.
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?
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.
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...
(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.
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.