Why Subversion is better than Git

A while back I had to make a decision, as the most senior developer on a team, if we should stick with the Git version control system. Git is extremely popular these days in the open source community. It was developed by Linus Torvalds to manage the Linux source code. And everyone wants to be as cool as Linus.

But hold on. Linux is not your average project. Certainly not the average project I work on. Linux is programmed by thousands of developers all over the world, with a hierarchy of committers and reviewers. Linux has a large volume of code. People using and making modifications to the source code are programmers, who can handle complex concepts who know why merge conflicts occur and when to use feature branches, release branches, etc.

My world looks different. I sit in an office with 2-3 onsite people. Some of them are graphics people who have a good sense of what looks good, but not a good grasp of resolving merge conflicts using vi. Some of them are managers, bosses, project leaders, product creators, who should be enabled to edit certain things such as wording, but who certainly won’t make much effort to learn anything new and will simply order me to do their wording changes myself if the system doesn’t work to their liking. This may not be everyone’s world, but it’s my world.

So it would be surprising to find that one system fits all sizes (although certainly not impossible, look at TCP/IP!). But it certainly can’t be assumed without evidence or investigation, that a system working for one world is the best solution for the other.

What do I want from a version control system? I want the following, in the following order (most important first):

  1. A system which can manage files between multiple users. A Windows share would suffice for this requirement. What I don’t want is me having to send a file to someone via email, me changing the file, them sending a changed version 2 weeks later back to me, and another 2 weeks after that, and me having to manually work out what changed when, and trying to make a combined version in a text editor. Or me working on my codebase and my colleague working on their codebase, and then 1 month later having to try and merge the results in a text editor.
  2. History. Who did what when, and why? If something breaks, who did it? Why did they do it? If I revert their change, what will I break? The ability to revert to a previous version.
  3. Branches. If more than one person creates a new feature, I want to be able to check stuff in, they check stuff out. But it shouldn’t go live yet. But live bugfixes need to happen. Multiple people could work on multiple different features, and one merges each feature into the “to release” history stream when they’re ready: in whatever order they become ready.
  4. Being able to create patches of changes, send them to other people, have them review them, etc. Actually I don’t need this functionality at all, but maybe I would if I worked on open source software.

OK let’s look at objectives #1 and #2, my most important objectives. As stated above, as many people should be using the system as possible (incl. non programming roles), in order to make me send/receive emails of various versions of stuff as infrequently as possible. Here’s my experience in this area:

  • At Uboot, a long time ago, we used to use CVS. There was only WinCVS at the time, a terrible program by all accounts. My manager Helge simply refused to use it. He said “I don’t need to use version control, that’s for programmers”. Therefore he was not technically able to do any wording, CSS or HTML changes. He had to delegate even the smallest thing to a web-designer or programmer.
  • A manager before that, when I suggested web design should be using version control, said “don’t even bother trying, web designers are too stupid to use version control”. He literally said that. I didn’t believe him. Years later at Uboot, the web designers were using CVS, thanks to my campaigning.
  • At Uboot, some web designers were better using CVS than others. Some could handle it, others would constantly get confused. Understandably, the error messages were terrible.
  • Using Subversion at Easyname (approx 5 people in total), managers, graphics people and software developers are able to work on the code base: anyone can alter wording, HTML, etc. Anyone can fix any bug.
  • Using Subversion on another project, my non-programming manager can alter wording in the HTML files I produce. That’s significantly better than him sending me Excel files with wording, and me building it in to the code. Not only is my life easier: it much less effort in total, meaning we can offer the projects at a lower cost to our customers, for same about of value for the customer.
  • Then, on this project, we switched to Git. The manager could just about handle checking in (although didn’t really understand the messages, there was a lot of “delete everything, check out everything again, try again” going on). The graphics department couldn’t handle it at all. They’d been working on a new version of the product for months, and had produced an un-checked-in tree of changes, un-merged with what development had been doing. Trying to check it in just resulted in errors such as ! [rejected] with no further info (literally, git is this unusable). Forget about creating branches or higher-level objectives of a VCS, this wasn’t even achieving objective #1.

Subversion is good because it’s simple and it has a good user-interface. Having a good user-interface is made possible (although in no way guaranteed!) by it being simple. Errors don’t happen often (as it’s easy for the user to have a model of how it works consistent with how it does actually work) and if they do, errors are clear and understandable, and often include a description of what to do next. Tortoise SVN is integrated with Windows Explorer and works perfectly, I think everyone who’s ever used it would agree. (Is there anything equivalent for Git?)

Subversion 1.5 (the latest version) even supports some fancy Git features. You can import all the changes from one branch onto another branch (“rebasing”) and it remembers which its imported, so next time you do them, it won’t import them again. You can “cherry pick”, i.e. decide that a particular revision should be imported from one branch to another, but no revisions before or after it: useful for applying a particular bug fix from development to live, for example, without carrying across any other new features. So there’s really nothing Subversion doesn’t do, which I would need.

So I took the decision to convert our repository away from the modern shiny “git” system, into the nearly-legacy (if you read open-source evangelists!) well-engineered easy-to-use Subversion. I haven’t looked back.

In addition (independent of distributed vs central source repositories), Subversion has so many well-engineered practical features:

  • Directories being empty and directories not existing are different states. Once a web designer created a whole structure of empty directories and checked them in to CVS only to see them not be checked out. On Subversion a directory can be empty on one revision, deleted on the next, replaced by a file of the same name on the next commit, etc. Neither CVS nor Git can handle this.
  • Want to revert your changes? Just type “svn revert”. I have watched a “Git expert” spend 30 minutes reading man pages to find out why the equivalent git command worked on modified files, but didn’t restore files which had been deleted. Reverting things is important, objective #2.
  • Binary files are automatically detected (in contrast to CVS).
  • Executable flag allows files to be marked as needing the UNIX “executable flag” (in contrast to CVS)
  • Files can be ignored based on versioned properties (i.e. *.class files, etc.). This is more elegant than creating a special file like “.cvsignore”
  • Want to commit with a different user? (e.g. shared check-out like on a live system) Just use the “–username” option or simply press return when prompted for a password and it’ll prompt you for a new username.
  • Absolute paths. You can execute “svn commit /home/adrian/checkout/file.txt”. This is convenient with Mac Finder: you can just drag a file from the finder to the terminal to gets its (absolute) path to appear. Neither CVS nor Git allows absolute paths for its commands.
  • The help is clear because the features are so simple. Check out the manual for svn log vs git log (shows the history of a file: how complex can it be!?)
  • You can do a quick fix on the live server and commit it. Subversion demands that the modified files be up-to-date before you can commit. Git demands that every file in the checkout is up-to-date, basically meaning you always have to pull the latest version from the repository and install it live, before you can commit the fix.
  • Don’t have Subversion? Don’t even know what it is? Subversion repositories are URLs, so you can just type it into a browser and see the files. CVS and Git repository descriptions are weird strings, so if you don’t have the software, you don’t know where to start.
  • You can force locking. You can specify that certain unmergable files should adhere to “lock, edit, commit & unlock” semantics. I use this for Excel spreadsheets, for example.
  • You can embed expandable keywords like $Revision$ into the source and use an option to say they should get replaced to e.g. $Revision: r213$ when a commit is done. This is useful because if you send a file to someone, they edit it and send it back, you need to know which version they originally got in case you’ve updated the file in the meantime. (One could say they “should do a checkout” but try telling a large many-thousand-person company to install a new version control system just to edit e.g. one wording file or an image, when they don’t even have physical access let alone administrative rights to their PC.)
  • Those $Revision$ tags don’t generate conflicts when merges are done. (CVS also replaces tags, but if you merge two versions together, CVS sees that the tag has been “modified” (by itself) in incompatible ways, and generates a conflict. Subversion normalizes such tags back to $Revision$ before applying merges.)
  • You can checkout only a subdirectory of the repository just by adding the directory to the end of the URL. (so on http://svn.x.com/project you can check out http://…/project/dir to get just “dir”).
  • Old servers can talk to new clients and vice-versa. This is good software engineering.
  • Output is copy-paste friendly. From the “svn diff” command you see your differences. You can copy/paste the filenames easily. In Git, you always have an extra “a/” in front of the name, e.g. “a/dir/myfile.txt”. Double-click on it and you can’t copy-paste it anywhere without having removing to remove the “a/” first.
  • Internally, Subversion separate logic from UI. A library of logic can be used from various different UIs. CVS tools all just wrap the command-line CVS tools (and always have a “command pane” where you can see the input/output to these tools, in case something goes wrong, e.g. you try and check in a file whose name contains a space!) It seems “git” has also been developed around the command-line-tool model. In 2008-11 someone suggested making a UI-independent library of functionality for git.
  • Subversion can handle Unicode file names.
  • SVN Externals are cool, for example a checkout of an application can check out the libraries as well, even if the libraries are hosted somewhere else. That’s better than checking the source of the libraries into the VCS, or the compiled form (e.g. JAR) or having a more complex build procedure

A few positive things to say about Git vs Subversion:

  • Git really is unbelievably fast. But is that actually a useful feature? For the Linux kernel, maybe. But I just did an “svn up” on my current project, it took 1.2 seconds (incl. server communication) and it was 1,684 files. On another project (uboot) “svn up” took 7.4 seconds and has 18k files. But I only do “svn up” once a day.
  • Grep -v. Because Subverison stores the original versions of all files it checks out, so it can send diffs to the server, if you do a “recursive search” for any string every file shows up double: once in the file, a second time in the Subversion’s internal directory. That’s quite annoying. Git has “git grep” but even if one uses “grep -v” they don’t show up for some reason.
  • Scrolling. Git automatically pipes the output of commands to a “more” program
  • “svn log” on a directory shows the differences to that directory object (which you rarely want), not all the files underneath it (which is what you always want). “svn info” shows the URL for that directory, “svn log <url>” shows the differences to all files (what you want).
  • Subversion renames don’t work too well: if you modify a file and someone else renames it you get a conflict, as opposed to your changes getting taken over to the new file name (i.e. contents changes and renaming being changes to two different aspects to a file, so should be mergeable). Does git handle this better? No idea, I didn’t understand git’s output when I tried to rename a file. (“git mv a b; git status” and “mv a b; git rm a; git add b; git status” produced different results, even though they should be the same according to the docs?)

By the way, when converting between version control systems:

  • Do always copy/convert the entire history, don’t just check in a “snapshot” of the current versions. Old versions are really amazingly useful. I regularly use “svn blame” on uboot and see changes from 2004 and beyond. Particularly satisfactory/useful if the change occurred at the time I wasn’t working for the company :)
  • Branches. Make sure to convert not only the “trunk” / “master branch”, but also any other branches or tags which are in use.
  • Send an email to all developers explaining how to download/use the new system (e.g. Subversion), how to make a checkout (e.g. the URL), and any username/passwords.
  • Other checkouts. Don’t forget clients of the VCS are not only humans, but all sorts of live servers, integration testing environments, daily build systems, etc. Make sure they get converted too.
  • Turn off writes to the old system. Keep the old system there (in case something goes wrong) but make sure it’s read-only.

(Subversion 1.5, Git 1.5)

18 Responses to “Why Subversion is better than Git”

  1. Stripes Says:

    Because Subverison stores the original versions of all files it checks out, so it can send diffs to the server, if you do a “recursive search” for any string every file shows up double: once in the file, a second time in the Subversion’s internal directory.

    Dodge, you need to be using ack, sir.

  2. Helge Says:

    Did I really refuse to use it? I think I did in the beginning but then used to check in myself. I could be mistaken however, that was many years back.

  3. Flo Lauber Says:

    hey adrian!

    git has a very steep learning curve. i think that is the very most important
    argument, why it’s not suitable for non-technichal staff (like designers).

    i couldn’t resist commenting on some of the comparisons you listed :)

    > Directories being empty
    $ touch path/to/empy/subdir/.gitignore
    should do it. not the most elegant way, though.

    > Want to revert your changes?
    > I have watched a “Git expert” spend 30 …
    you saw me reverting changes it in seconds :)

    > Files can be ignored
    i don’t think SVNs Ignore scheme is good.
    first of all, it is hidden deep in some obscure svn properties (which names i cannot remember due to seldom usage), instead of a simple
    plaintext file (.gitignore).

    further, the last time i used SVN’s ignore feature, i coudln’t find a way to
    define recursive ignore patterns.
    now thats ugly. do i really have to create a ignore-property for VI .swp files
    for every subdir?

    with git you have a single .gitignore in the project root. single point of
    configuraion (in my opinion the best way to handle this kind of issue)
    and it can handle global patterns (*.swp), directories (log/)
    and single files (src/lib/foo.bar).

    > history in git (was help is clear)
    since git is very complex and can do lots of stuff, the help is very elaborate. this is
    not very usable, indeed. (learning curve argument)
    or better: it’s not beginner-friendly. but it is definitely expert-friendly.

    working with git’s log features has often helped me finding stuff
    faster. on the other hand, i really don’t unterstand why ‘svn log’ doesn’t
    automatically pipe to a pager. i think the cases where you would read the log
    output in a pager outnumbers the others by far.

    > You can force locking
    afaik, not being able to LOCK is a feature of DVCS, not a bug and not
    i might be wrong on this one.

    > Output is copy-paste friendly
    > .. extra “a/” in front of the name ..
    i agree. that sucks. has bogged me several times, too.

    > Internally, Subversion separate logic from UI
    git also strongly divided lowlevel (“plumbing”) and highlevel (“porcelain”) tools.
    git-pull, for example, is a shell script.

    > Git really is unbelievably fast.
    > But it only do “svn up” once a day”
    that’s right. i do ‘git log’ and ‘git diff’ pretty regulary. especially
    for a diff it’s great when you have all the information locally instead
    of having to talk to the server for it.

    > git error messages
    i totally agree. git’s error messages are often misleading and/or only understandable by
    people who know the internals of git.

    At some points you say svn is better, because it can do things,
    _CVS_ couldn’t do. (but git can do; sometimes even better).
    These would be (svn & git) > cvs reasons.

    btw there’s a TortoiseGit in development. (http://code.google.com/p/tortoisegit/ ).

    best wishes,

  4. adrian Says:

    Thanks for your detailed answers!

    @Stripes – Thanks for the tip.

    @Helge – I’m not sure, but certainly at the start CVS was used by nobody, not even web designers. I had to fight hard to get CVS adopted by web design and even so certain things like branches always caused problems to the less technically minded staff. You certainly refused to use it at the start, but that may have changed as time went on. But I understand your rejecting of it – WinCVS was a nightmare – the tool was at fault here – the tool should fit the people (be easy enough to use so as to be accepted by them) not the other way around.

    @Flo – Git revert – That’s what my git expert said too, until he tried it. But maybe it’s easier than it seemed at the time, once you know how.

    Files can be ignored – Yes you’re right about the recursive feature. I’ve never needed them to be recursive but I can imagine there are plenty of situations where you do.

    “git log” usability – True but can you name me the way to get the log to follow file moves/copies? It’s buryed many pages down on the documentation, and there are many options described similar. For example “-M Detect rename” (that’s the entire docu) is not the option I was looking for. SVN has this on by default. I think one of the reasons the SVN docu is smaller is because it does the right thing by default, but maybe I’m wrong.

    “svn log” pager – True.

    Library – True, but it’s still a collection of command-line tools like CVS. I don’t think that’s the right way to write software, as the only way to interact with command-line tools are arguments and lines of result. To interact with a library you need richer parameters and return values, i.e. objects and structures, which can contain other objects and structures.

    Speed – But “svn diff” and “svn log” are also fast. This repository (28k commits): “svn diff” on a file took 0.01 seconds. “svn log” took 0.9 seconds. True if you do it on a directory it takes longer. On the entire checkout (12k regular files) a svn diff took 1.3s (but this wasn’t the first time I ran it – probably everything was in FS cache), and there were very few changes).

    Comparison to CVS – True, that deviated from the title a bit.

    Tortoise Git – That’s good to hear. I’m sure many of these usability issues will go away with time (the ones that are just down to bad docu and bad defaults.). I mean Tortoise CVS basically hid most of the CVS options. (e.g. “yes I want recursive!”).

    But there is still the feeling at the back of my mind that Git solves a problem I don’t need solving, and in doing so, necessarily alienates a lot of users who not only don’t need those problems solving, but also aren’t going to take the time, or may lack the education necessary, to understand the solutions to them.

  5. Mark Phippard Says:

    Nice post. You are brave to be willing to risk the flames of the git zealots. It is good to hear some real-world feedback.

    We, Subversion, are working on re-writing the way the “working copy” is managed for the 1.7 release (this summer). It will get all those .svn folders out of the working copy which should solve the grep issue and it will also bring massive performance improvements by eliminating all of the crawling of the working copy that has to happen today.

    The upcoming 1.6 release brings some improvements to rename handling. Specifically, adding the concept of a “tree conflict”. So for example, if you rename a file and then run update, and the update brought in changes to the renamed file, this would raise a tree conflict so that you could review those changes and incorporate them into the renamed version. Today, in 1.5, this whole process if very silent and you could easily miss the situation.

    Anyway, thanks for the posting.


  6. C. Michael Pilato Says:

    > “svn log” on a directory shows the differences to that directory object (which you rarely
    > want), not all the files underneath it (which is what you always want)

    ‘svn log’ on a directory can yield somewhat confusing results if your directory isn’t up-to-date, but yes, it does show changes to files inside the directory, exactly as ‘svn log URL’ does.

  7. Jakub Narębski Says:

    Directories being empty: In Git currently you have to do workaround by keeping for example empty .gitignore file. This is not a fundamental issue, though, and might be changed in the future to allow Git to be configured to track empty directories.

    Reverting your changes to some file?: Supposed ‘Git expert’ wasn’t much of an expert if he/she didn’t know about git checkout -- <file>, git checkout HEAD -- <file> or (in newer Git) git reset -- <file>. Unfortunately (for Subversion users) ‘revert’ means something different in Git than in Subversion… you can always make ‘revert-file’ alias.

    Binary files are automatically detected in Git (and you can use gitattributes to override detection based on pathnames). The title is “Why Subversion is better than Git” not “better than CVS”, isn’t it?

    Executable flag (executable bit) is supported in Git. Symbolic links are also supported.

    Ignoring files: I disagree, properties are worse solution than ‘.gitignore’ file(s) (and ‘.git/info/exclude’, and core.excludesFile). First, they are not recursive. Second (correct me if I am wrong) cvs:ignore is client property, so it cannot be propagated (like tracked .gitignore file can).

    Want to commit with a different user?: ‘git commit –author’. By the way, if you are applying patch with description from email using ‘git am’ authorship of a commit is set automagically.

    Absolute paths should now work with (modern) Git. Well… I have checked that ‘git add /home/adrian/checkout/file.txt’ works.

    The help is clear (example of ‘svn log’ and ‘git log’): more features (like e.g. –grep, or –author, or –since) means longer manpage. But I agree that Git manpages might be cleaner and more newbie friendly.

    You can do a quick fix on the live server and commit it WTF? You can do a commit in Git keeping some files in working directiries dirty, never mind not updated… Perhaps I don’t understand this issue…

    Subversion repositories are URLs So are Git (well, that, or scp-like expressions). And you can put HTTP ones in browser (although you won’t see much if repository is bare, i.e. without working area, as it should be for public repositories, usually), and you can configure gitweb to share the same HTTP URL as repository. Access via SSH or anonymous git:// protocol is much faster; this might change in the future when “smart” HTTP server will get finished.

    You can force locking. True, that is next to impossible in Git. Git is inherently distributed SCM. But I think one would be able to cobble something using hooks and locks / lock server… OTOH you can have custom merge drivers (configured using gitattributes) in Git.

    You can embed expandable keywords: Git, because of its policy of not updating file in working directory if its contents didn’t change, support only very limited set of keywords out of the box, and they have to be turned on using ‘ident’ and ‘export-subst’ gitattributes… or you can use set of smudge / clean checkout gitatribute filters.

    You can checkout only a subdirectory of repository: currently it is not possible in Git, but patches for ‘partial checkout’ are floating on git mailing list.

    Old servers can talk to new clients and vice-versa. With Git too.

    Output is copy-paste friendly (where you mean that ‘svn diff’ doesn’t have prefix in filenames, i.e. it is “patch -p0″ compatibile patch). For Git it was more important to be compatibile with commonly used “patch -p1″, but if you really need it there is ‘–no-prefix’ option to git-diff.

    Subversion can handle Unicode file names. Well, it depends on what do you understand by this, but Git does also support international characters in filenames.

    SVN Externals are cool. Git submodules are svn:externals done right :-)

    Git really is unbelievably fast. But is that actually a useful feature? If diff or status, or commit on the whole project takes seconds or minutes rather than fraction of second, it does matter, because it changes workflow.

  8. adrian Says:

    Title: Why Subversion is better than Git not better than CVS – True, sorry about that.

    You can do a quick fix on the live server and commit – That doesn’t work for me. In the following example, I alter a file, check it in locally. This file is up-to-date even though the checkout isn’t up-to-date as a whole. After a pull the file has not been altered (showing that it was up-to-date). But only after the pull (updating other files I don’t want to change) can I do a push.

    vi Wizard.class.php
    git commit Wizard.class.php
    md5sum Wizard.class.php
      a3472e35266331b664e547feedfd459a  Wizard.class.php
    git push
      ! [rejected]        master -> master (non-fast forward)
    git pull
    md5sum Wizard.class.php
      a3472e35266331b664e547feedfd459a  Wizard.class.php
    git push
      fc1b1d7..5edbc69  master -> master

    Other points about Git’s usage – Thanks for the tips.

    I think as a system increases in complexity, the number of clicks or options one needs to achieve a given task necessarily increases. For example in Google Spreadsheets (simple) there is a “formatting” drop-down where I can select the 0.00 format. On Excel I have to right-click, select formatting, select “number”, then choose the number of decimal places. I think because Subversion is simpler, those things which are also possible with Git, are more accessible in Subversion: for example “svn revert xxx.txt” is easier than the 3 methods you described. Easier means a larger set of people will use the feature, meaning the tool as a whole becomes more useful, as there is less emailing of files. Of course it comes at the trade-off of other features not being available at all, however if they’re not needed (depends on what you’re doing) then that’s a good trade-off.

  9. Jakub Narębski Says:

    About quick fix on the live server and commit: correct solution (correct as in: you would be able to reproduce state on live server that you had from version control) is to either use different branch han ‘master’ on live server (like for example ‘live’ ;-)), or push to separate remotes layout

    git push
    fc1b1d7..5edbc69 master -> remotes/live/master

    Or configure to allow non-fastforward push, but YMMV.

    Whether svn revert file is simplier than git reset -- file is I think the matter of taste. git-revert is taken to mean create a commit which reverts changes in given commit (cherry-picking reverse of commit, patch -R…).

  10. adrian Says:

    Yes you are definitely right about intermediate commits creating a non-reproducible state, I hadn’t thought of it this way.

    I tried your git reset -- file but it didn’t work for me.

    git rm RobotRunner.php
    git status
     deleted: RobotRunner.php
    git reset -- RobotRunner.php
     src/lib/Strings.php: needs update

    I think by “needs update” it means I need to do a “commit” of some other unrelated files, right? (The naming is not necessarily wrong, but for sure confusing for CVS/Subversion users!). Well I don’t want to do a commit, I just want to do something similar to svn revert.

  11. Tyler Breisacher Says:

    For the use of reset, this may help: http://blog.plover.com/prog/git-reset.html

    But if you just want to revert local changes, not undo changes from an existing commit, you may want to do a checkout, not a reset. I admit this terminology sounds weird coming from svn, but once you start thinking of your .git folder as its own repository, it makes sense. git revert is like svn reverse-merge.

  12. Nathanael Jones Says:

    It’s extremely unfair to compare subversion’s GUI to git’s command line.

    Git, in my opinion, now has (multiple) UI wrappers that are far more intuitive than TortiseSVN has ever bin. And yes, there is TortiseGit, although SmartGit is much better.

    Give SmartGit a try – I think you’ll realize Git is much easier to teach than SVN, especially to somehow who hasn’t used either before.

    Every SVN user I’ve introduced to Git has switched and never gone back.

  13. Trolololol Says:

    While I didn’t read your post, I’m glad you wrote this because this probably gives the git zealots and Linus worshippers a heartattack and foam from their mouth.

  14. phloidster Says:

    Git is a trainwreck.

    And the opening comment said it all, the git-heads thnk because Linus created it, that makes it ‘better’. Linus is a smart guy, but he is not right about everything. Git may work for Linux development, because of it’s specific characteristics, but for most software development it is the wrong tool to do the wrong things.

    First, the whole ‘distributed’ version control idea is just plain idiotic. All it does is encourage cowboy practices commonly seen in environments where there is no version control, or certain individuals think they are too clever to need it or be constrained by any kind of process that values the stability of the code-base as a whole, rather than the convenience of a single developer.

    Git allows, even encourages, myriad bad habits. I have seen inexperienced teams lose changes because there is no ‘master’ repo, and sync’ing with everybody is just not scalable. Btw, sometimes very capable and experienced individuals can still be part of an inexperienced team. It takes a kind of discipline to collaborate with even one more developer, and most of the git fanboi crowd are prima donna types who just want to do what they want.

    A tool that is very fast and handles merges, etc, has it’s place, but don’t call it version control.

  15. Wanyoung Says:

    I totally agree with you.
    Git was born to handle special case for special people.
    Subversion was born to handle common problems for common people.

  16. Robert Says:

    I think git makes it much more suitable to manage user stories within agile projects. If you work inside the agile universe, you have to organize your code basis of all the work packages and stories of your project in an flexible way.
    User stories are build with several branches. You can collect these branches and sum them up to releases. Merging between branches and releases is done in seconds. I used SVN during the last 7 years and merging branches was always a time consuming and confusing issue. From management perspective I think git is the perfect tool to manage the code basis of your project or product in a smart agile way.

    Platforms like Bitbucket.org or Github.com provide you a great solution to collaborate within your (technical) project team. These platforms have great possiblities to discuss code modifications and it also encourage review processes and quality management. But this is another chapter, it’s not git related… Interaction and sozializing between developers becomes more important.

    with git release cycles become more flexible and you can reduce your time to market without reducing your quality, because of its faster and easier concept of merging and shifting branches. It fits perfectly into the big picture of scrum.

  17. Mike Says:

    Replying to Robert talking about branches. In true agile projects, you don’t branch. I learned this from Kent Beck’s books and articles early on and that really helped me a lot. I used to be the branch king in the 90′s and up to around 2001/2002. Then, I went agile and in 10 years, have only truly “needed” a branch twice across many tens of projects.

  18. Rogerio Senna Says:

    I work with some SVN repositories. I do not use branches. But every single day I must to deal with some “tree-conflict”. Lots of stupid merge errors, which would simply not happen if I were using Git. And I know that for sure: I use Git-SVN with some of those (but not all, because Git-SVN does not grok svn:externals).

    I am a Windows developer. I am certainly not a “Git zealot”, whatever that means. But, man, I wish I could use Git (or Bazaar, or Mercurial – again, I’m not a Git fanboy, I just know there *are* better tools than the one I’m forced to use).

    Yes, SVN is for common people. Just like Visual Basic, right? (sigh)

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

For inserting HTML or XML please remember to use &lt; instead of <