Slashdot Mirror

← Back to Stories (view on slashdot.org)

Git Adoption Soaring; Are There Good Migration Strategies?

Posted by Soulskill on from the git-while-the-gittin's-good dept.

Got To Get Me A Git writes "Distributed version control systems (DVCS) seem to be the next big thing for open source software development. Many projects have already adopted a DVCS and many others are in the process of migrating. There are a lot of major advantages to using a DVCS, but the task of migrating from one system to another appears to be a formidable challenge. The Perl Foundation's recent switch to Git took over a year to execute. The GNOME project is planning its own migration strategy right now after discovering that a significant majority of the project's developers favor Git. Perhaps some of the projects that are working on transitions from other mainstream version control systems can pool their resources and collaborate to make some standardized tools and migration best practices documentation. Does such a thing already exist? Are any folks out there in the Slashsphere working on migrating their own project or company to a DVCS? I'd appreciate some feedback from other readers about what works and what doesn't."

42 of 346 comments (clear)

  1. Git links by Anonymous Coward · · Score: 4, Informative

    Why Git Is Better Than X.com/ YouTube - Tech Talk: Linus Torvalds on git (yeah, I'm a convert)

    1. Re:Git links by grumbel · · Score: 5, Informative

      Some things git is bad at:

      - no of partial cloning, so a big history means lots of stuff to download, this is especially bad when it comes to binary files
      - no way to download just a single file or directory, a user always has to clone the whole repository

    2. Re:Git links by Drinking+Bleach · · Score: 3, Informative

      For problem one: git clone --depth 1 (or however far back you want your history to go); note this severely cripples git's abilities and isn't very useful at all unless you're on dialup still.
      For problem two: this isn't a real problem with git, but rather with your organization. Multiple projects don't belong in the same repository, it's as simple as that.

    3. Re:Git links by grumbel · · Score: 4, Informative

      Problem two *is* a problem with git, it has nothing to do with how you organize a project, since you can never guess what a user might want. Simple example: I would like to look at the latest version of a file in the linux kernel, with git I have to download the whole beast when all I want is a single file, which is neither pretty nor fast.

    4. Re:Git links by Drinking+Bleach · · Score: 3, Informative

      I hadn't really thought of that, I had assumed you were referring to Subversion's rather common case where multiple projects are stored in the same repo, and you checkout different directories to access one of them.

      Anyhow, most, but not all, public git servers have a gitweb or similar attached, which will at least let you browse and download files from the tree if you need to. For example, grabbing the latest README of Linus' Linux tree can be had via http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=README;hb=HEAD

      Git itself doesn't provide any mechanism for it, however, but it's fairly unusual to be interested in a specific file rather than the entire project.

    5. Re:Git links by maxume · · Score: 2, Informative

      Unless you are intensely involved in a project, browsing for the single file using some alternative interface is probably going to be easier. I.e.:

      http://github.com/github/linux-2.6/tree/master/kernel/fork.c

      That doesn't work if the repository doesn't have an alternative interface though (but for projects you are involved in, the download only needs to be the difference between the internal and external repositories, not the entire history).

      --
      Nerd rage is the funniest rage.
    6. Re:Git links by davebaum · · Score: 2, Informative
      Git and Hg branches are actually quite different. In Git, a branch is just a pointer into the DAG of changesets. If you are "on" a branch and commit, the pointer is moved to the new changeset. But you can manipulate that pointer arbitrarily and point it at any changeset. These pointers are local to a single repository, although I think you can map them so that branch X in repo A corresponds to branch Y in repo B, etc.

      In Mercurial, every changeset is marked as belonging to a single branch (the default is a branch named "default"). This marking happens at commit time and cannot be changed afterwards (short of creating a new commit). Typically a changeset inherits the branch name of it first parent, but you can always mark it differently before the commit. So instead of a branch being a pointer to a single changeset, it actually identifies some subset of the DAG, and when you refer to a branch you are asking Hg to figure out the tip of the DAG subset marked with that branchname. Note that since the branch name is recorded internal to the changeset, it remains the same for all clones of the repository.

      Personally, I think the git mechanism is more flexible, but the hg mechanism suffices just fine for basic use cases, and leads to fewer surprises among new users.

    7. Re:Git links by EsbenMoseHansen · · Score: 4, Informative

      In case you were looking for answers rather than abuse: I have used both. For me git does what svn does, plus the following in order of most important first.

      1. Locals checkins, that is, you can check in even if offline (on the train, net down, whatever) and you can commit without the rest of the developers getting it. The latter is nice if, say, you have to write an email first to tell the other developers first.
      2. If you want to checkout your code on some meaty machine to test, without pushing the commit to the central server just yet
      3. Have a full tree locally, which means that history dependent operations works offline and fast
      4. Local branches - the advantages is quite obvious

      Of course, this is for me, and all points might be irrelevant for you.

      --
      Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
    8. Re:Git links by prockcore · · Score: 2, Informative

      Frankly, no one, including yourself, ever mentions a reason WHY I should switch.

      I can give you the reason why I switched.. which may or may not help.

      With SVN, I found that branching was so involved that I wouldn't do it. Instead, I would check out code, work on it, and wouldn't check it back in until I had completed whatever I was doing... which may be days or weeks away.

      Checking code back in with SVN almost became a "release".

      With Hg, I pull down a copy of the code, make changes, commit those changes to my local repo, even if things are so broken they don't even compile. Then, when I'm done, I'll push all my commits back to the server.

    9. Re:Git links by Schraegstrichpunkt · · Score: 2, Informative

      Some of our submodules are 20 times bigger than the Linux kernel and there is no way to subdivide them more than that.

      But do they accept more changes than the Linux kernel does? Linus Torvalds's 2.6.28 tree alone (which goes back to 2.6.12-rc2, dated April 16, 2005) has 120035 commits. That doesn't include any branches that others have worked on.

      --
      http://outcampaign.org/
    10. Re:Git links by Geoffreyerffoeg · · Score: 2, Informative

      Ignore tha fanboys. If anything, use them as statistical evidence that there might be something worthwhile here. :-)

      Why git for a SVN user? There's nothing better than trying it for yourself (git-svn clone svn://whatever, then hack on it with git, then git-svn dcommit). But until then, two big points:

      1. It's distributed. I can make lots of commits without pushing them somewhere public, which is good for the same reasons that hitting "Save" often is good, without being worried that I've broken the build for everyone.

      Relatedly, I can put my stupid personal projects in git from the beginning, without bothering to set up a server. But if I find I do want to share it with anyone or add anyone else as a contributor, there's basically no difficulty in doing so.

      2. Git lets you rewrite your local history. If I didn't like a commit, I can edit it before sending it off. My workflow is often edit-commit-compile-test, rather than edit-compile-test-commit, which lets me remeber why I thought editing this file was a good idea. And if it's not, I can delete that commit from history, rather than having yet another one to revert it. And then when I'm done with this task, I can squash all my temporary commits down to two or three, one for each major part of what I did. As a side benefit, my commit messages only have to be useful enough for me, since I can edit them before pushing commits.

      (Obviously, once you publish a commit, it's a pain to retract that commit from everyone else's repos.)

      Another part of rewriting history is that rather than trying to do a merge when you've been hacking for a while, you can save your local commits in another branch, update to upstream, and cherry-pick the ones that make sense individually and edit the ones that need to be edited, creating a linear logical history rather than a merge between branches. This will make you saner a month later when you're trying to figure out why the code changed as it did, and you don't have to follow multiple branches and see how they were resolved.

  2. Re:Adopt a git... by WarwickRyan · · Score: 5, Informative

    It's more than just an moron, it's an nasty, stubborn, selfsentered and selfish moron.

    "Our neighbour is an right old git" could be used to describe an elderly neigbour who, say, regularly blocked your driveway because your car got in the way of the sunlight on his garden.

    The old neighbour from Dennis, or Victor Meldrew from One Food In The Grave are both fine examples of gits.

    It's like a weaker version of the c-word.

  3. If it looks like a tree, you'll probably be fine by James+Youngman · · Score: 5, Informative

    If the system you are migrating from manages trees, you should be fine. CVS migration is pretty easy and I understand that Perforce works quite well too (in both directions!). Most of the migration tools are listed in the GIT FAQ.

    The places where people are likely to have trouble is migrating from tools that don't understand that there's more than one file. For example, RCS and SCCS both support branches, but in a completely different way to git (branches are per-file, they're not for the whole repository). This means that during conversion, something useful has to happen with them, but the right answer isn't clear to a program. If versions 1.1, 1.1.1.1, 1.1.1.2 and 1.2 of file "foo" exist, then versions 1.1.1.2 and 1.2 are on different branches and either may be the older revision. It's not clear if revision 1.43.1.3 of file "bar" is the same "branch" as "foo" 1.1.1.2 or not. Because RCS and SCCS deal with single files only, it's not possible to find an answer to these questions in the history files at all - if there is an answer, it's just a convention of the user. Essentially what's happening here is that the git import process requires information which isn't represented in the files you're converting from. For what it's worth, migrating from SCCS or RCS to CVS has a similar problem.

    Personally, I've migrated from CVS to git for findutils (well, Jim Meyering did the actual migration; he migrated coreutils too). I haven't regretted migrating at all. It took me a long time of using git locally before I was comfortable migrating the master repo, though. As a git beginner the thing I found most worrying was that I found it hard to envisage the effect of the git command I was typing. The thing it took me a long time to figure out is that with a distributed version control system, it's safe to screw up your local copy, as long as you don't push the result.

  4. Re:Adopt a git... by Wild+Bill+TX · · Score: 5, Informative

    Quoth Linus Torvalds, "I'm an egotistical bastard, and I name all my projects after myself. First Linux, now git." :)

    --
    Audioscrobbler
  5. strategy by carnicer · · Score: 4, Informative

    I have migrated to svn many repos from older stuff, like SCCS and VSS. Migration strategies are important, and to decide about them you need to answer a few questions. First of all, ask yourself if git or DVCS is the best option for you, your project and your company. Just don't be led by hype. It may be that a centralized VCS like svn may be a better option. There are tools to make them perform as DVCS, like the plugins git-svn and bzr-svn. Second, ask yourself how much of the project history is needed, if any is needed at all. That may save you lots of time, disk, chaos and entropy. When migrating, it is very important to tidy up the repo. Purge unnecessary files, binaries, archives, branches, etc. I have seen people who use VCSs like a trashcan. Bad practices may sink the repository performance. After migrating, make sure users know how to use the repo and that understand the basic VCS concepts, either generic or specific for the VCS of choice. Try to remove practices and concepts from the older VCS. As you mentioned it, best practices are very important, and they are not easily found on literature. There is more I could say, but I guess by now it's ok.

    1. Re:strategy by bheading · · Score: 3, Informative

      It may be that a centralized VCS like svn may be a better option.

      I cannot conceive of a scenario where this is true. In any case, you can use Git or any other distributed tool as a centralized VCS if you wish. Just tell all your developers to merge their code into the central location, and not to clone from each other's repositories. Dead easy. Although the idea that anyone would seek to make those restrictions makes no sense.

  6. Re:bzr vs. git? by kripkenstein · · Score: 4, Informative

    I always though bzr had the edge on git in terms of being a better DVCS. Is there a reason why the article seems to think that git is the default?

    No such thing as 'better' here.

    Bazaar was the runner-up DVCS, and rightfully so, but it has both advantages and disadvantages. Git is faster and currently more popular. Bazaar has an easier interface, better GUIs, is more easily extensible (Python), and runs better on non-Linux platforms.

    So which you prefer is a matter of what you are looking for.

  7. Re:Why is it soaring? by kyz · · Score: 4, Informative

    It's four good reasons.

    1. You can use git for any purpose. You have to pay serious coin before you can use Bitkeeper for any purpose.

    2. You have the freedom to see how git works, down to every last line of code. I can't comment on whether Bitkeeper also includes this level of freedom.

    3. You can make any damn changes you want to Git, without prior approval.

    4. You can pass on all these freedoms, and the freedom to use your change, to anybody you want. It was precisely the fact you can't do that with Bitkeeper that led to it being dropped by the Linux developers and replaced with a coded-from-scratch replacement.

    --
    Does my bum look big in this?
  8. Re:Why is it soaring? by anarxia · · Score: 3, Informative

    Another reason is that the bitkeeper license prohibits users to work on competing products.

  9. Re:I want to use git by anarxia · · Score: 4, Informative

    Tortoisegit. Haven't used it so I can't tell you how stable or complete it is.

  10. Re:Meanwhile... by bheading · · Score: 5, Informative

    I'll pray for your soul. There's nothing worse than a group of managers who think that the world will get better when Clearcase is employed. I swear, that tool seems to be deliberately designed to slow you down.

    Git or BK command :

    git pull

    Clearcase command :

    cleartool findmerge -avobs -fversion MYLABEL -merge -gmerge

  11. It's not so hard to do by bheading · · Score: 2, Informative

    It's not surprising that developers increasingly favour distributed version control. It's a much more flexible way to work - and if you need to continue working in a centralized way, you can still do that.

    If you're migrating to Git, there are a few things you need to account for. Do you want to migrate the history, or make a clean break using the current head of the tree ? Migrating the history is usually hard if it is in a commercial tool, since commercial companies quite obviously do not design their tools to make it easier for you to abandon them (some provide export tools). If you choose not to migrate the history, you have the issue of having to keep the old revision control system around to debug/fix/review older releases.

    You need to be clear about your decision. Import some example code into Git (perhaps from your existing repository), put it on a server and ask your developers to play with it to make sure they're happy with the feel and that they're confident they can work with it. Make sure you practice doing things like merging conflicts and merging older maintenance branches. If you do this right, most of your developers should be fairly enthusiastic about the switch when it comes. Make sure you account for Windows users - Git isn't so hot over on Windows and I don't think there is an official stable Windows release yet.

    Other than this, there's really very little to it.

  12. Re:Adopt a git... by TapeCutter · · Score: 2, Informative

    GP here or "useless git" as my farther used to say. The word originaly comes from foundry workers in the north of England, a "git" is the bit of metal left on the cast where the hole in the mold was. The original metalic git was useless and in the way. - At least that's how BBC's Time Team tells it.

    I wonder if Linus knows?

    --
    And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
  13. Re:Why is it soaring? by Anonymous Coward · · Score: 1, Informative

    1. It does the DVCS work as well as bitkeeper
    2. It is free software in both senses of the word
    3. It doesn't have a non-compete clause (a very large number of developers don't tolerate such crap)
    4. It has reached critical mass (in fact, it is, like the Linux kernel, far above the critical point), and there are so many good people working on every aspect of git (core, enhancements, CLI interface, GUIs, IDE integration plugins, and even "tortoise" crap for the lesser capable) that it is making a LOT of progress, very very quickly.

    So, while bitkeeper has superior UI tools, that won't last long. That doesn't mean you're wrong at using bitkeeper in your company, as bk is a far, FAR better VCS than anything else in the proprietary software world.

  14. Re:Why is it soaring? by gmack · · Score: 4, Informative

    It's worse than that. The bitkeeper author at one point tried to extend that as a ban on anyone who works for a company that has a competing product with bitkeeper.

  15. Re:Why is it soaring? by Anonymous Coward · · Score: 1, Informative

    Actually, behind the hood Git is technically way superior to BitKeeper.

    The only thing they really share is using the
    distributed model. In other respects, Git is to BitKeeper like Svn is to CVS. Like CVS, BitKeeper uses per-file revisioning, with all of the subtle problems it entails. Git, like Svn, uses a solid approach of revisioning trees.

    Another thing is that Git understands branches, BitKeeper only has the concept of trunk. This means no cheap branches, and makes merging a pain (you can't even try to _compile_ a merge to check your conflict resolutions before you commit).

    The only reason to use BitKeeper is that your revision history is locked into its proprietary format.

      - Kristian.

  16. Re:Why is it soaring? by David+Gerard · · Score: 3, Informative

    Even Microsoft don't use Visual Source Sink for their own code. (They use Perforce by preference.)

    --
    http://rocknerd.co.uk
  17. Re:Bazaar by Anonymous Coward · · Score: 3, Informative

    huh ? mercurial has no issue with revisions numbers, revisions are indexed with a hash just like git . The sequencial numbering is available as a convenient alternative for referring to a rev, that's all.

  18. Re:Git + Eclipse by Jraregris · · Score: 2, Informative

    When using git with Eclipse I've found it to be most useful to use the git plug-in, but use the command line for actual git action. The plug-in displays useful information about file changes and branches, while the command line offers quick, clean and expressive execution of git commands.

  19. Re:Bazaar by oojah · · Score: 2, Informative

    hg has both a revision number and a changeset id. The revision number is human readable and useful within a particular repo. The changeset id is unique across repos, the same as git does.

    --
    Do you have any better hostages?
  20. Re:Darcs by BlueCodeWarrior · · Score: 2, Informative

    Check out GitForDarcsUsers. Also, you may be interested in why ghc switched to git.

  21. Re:bzr vs. git? by kripkenstein · · Score: 2, Informative

    The video is from almost two years ago. Back then, Git and Mercurial really were the main options.

  22. TortoiseGit: the best shot at a Windows GUI by Qubit · · Score: 2, Informative

    At work we're trying to get all our our repos moved to Git. We moved off of CVS to SVN a year or so (which was a huge improvement), but now that all of the non-programmers in the office are used to using TortoiseSVN, lack of a good windows GUI for Git has been a bit of a roadblock.

    The msysgit folks started work on Tortoise-inspired GitCheetah GUI, but that project basically fizzled out. Lots of people wanted a Windows GUI, but no one had both the resources and drive to step up and do it.

    Then, exactly two months ago, Frank Li started working on TortoiseGit. From what I can tell, this is a fork of TortoiseSVN with most of the Subversion guts pulled out and replaced with git commands. TortoiseGit is not done yet: 'git add' has some issues, Submodules don't seem to work at all, etc..., but development on the tool is in high gear and the primary developer is going the extra mile to help users.

    If you're looking to deploy tools right now, gitk is a bit more powerful than the log in TortoiseGit, but might be more confusing for naive users.

    --

    coding is life /* the rest is */
  23. Re:How does it work with non-static IPs? by arrenlex · · Score: 2, Informative

    There's no way to pull from a repo that's behind a NAT unless you have sufficient control over the NAT to forward a particular port to a specific machine behind it. This is the same as svn -- how can you access an svn server that's behind a NAT? Only by having its relevant port forwarded.

    However, if you are in a coffee shop and you want Sue to have your devel history, you can push to Sue instead of having Sue pull from you. Sue will then merge your pushed changes into her working copy when she feels like it.

    Equivalently, you can set up another git repository on your home server which has a static IP. Then, you pull from and push to your home server, which you can access from anywhere with your laptop, and other people also pull from your home server. I used this approach when I was developing from home and didn't have time to make sure permissions on everything were okay and granting other developers ssh accounts on my machine, and didn't have time to set up an http server for the repo.

  24. @#$@#$ git! by Anonymous Coward · · Score: 5, Informative

    I curse more when I use git than when I use Windoz (and those are the only times I curse). Git's design is really that bad (from a user perspective).

    Git is fully distributed (with no "authoritative" source), but it doesn't give you any tools understand/manage the distribution of files. If you have a work group with more than a few people, you are constantly asking what repo (and what access method to it), what branch, and what (bombastically long) revision. It's fine for 1-2 people, but then any version control system is fine for a small enough group.

    The documentation helps little. When you do "git help merge", you don't @#$@# care that this is the front end to multiple merge methods. You just want the stupid thing to work. If it's a special case, then you'll look for an advanced technique; but you are stuck reading through all this crap trying to figure out what really matters. No offense to the people working on git docs. It used to be awful, now it just sucks. The problem is more in the user interface design than the docs.

    There are over 100 git commands, and a command can do radically different things depending the the switches and target syntax. It's more confusing than any other revision control system that I have worked with.

    I use git because I have to, not because I want to (like Windoz). After using it for months, I still routinely get stuck trying to figure out the right mix of commands, arguments, and target syntax needed to get common things done.

    Git can do some (nice) things that subversion can't, but it creates so many problems that you haven't gained anything.

    I've heard good things about mecurial and bazaar. I wouldn't recommend git to anyone I liked (but it's perfect for perl :-).

    1. Re:@#$@#$ git! by Anonymous Coward · · Score: 1, Informative

      Git is fully distributed (with no "authoritative" source), but it doesn't give you any tools understand/manage the distribution of files. If you have a work group with more than a few people, you are constantly asking what repo (and what access method to it), what branch, and what (bombastically long) revision. It's fine for 1-2 people, but then any version control system is fine for a small enough group.

      This is a wetware problem. If you are managing a product with git (or any distributed version control system) there must be one repository where the product is built from. With Linux this is Linus's repository. Everyone works on stuff and tries to get that stuff into his tree, and he often argues about why their changes are wrong and shouldn't go in. There are levels of indirection because of subsystem maintainers who also get to argue with developers before letting changes into their trees.

      When stuff does get into Linux's tree then everyone else pulls it back so all the other subsystem developers get that, and Linus publishes the product -- an official (or release candidate) Linux kernel source.

  25. Re:How does it work with non-static IPs? by NTmatter · · Score: 2, Informative

    There aren't any strict rules saying that people have to pull straight from your laptop.

    In terms of non-distributed VCSes, would you ever host a your repository on a machine that other people couldn't access? It would always be somewhere publicly accessible.

    For this kind of situation, you'd probably have a public development repo that's separate from your official repository. This would give you a set of repositories that looks like:

    official - The authoritative repository, controlled by some kind of integration manager

    jim-dev-public - Code that Jim is ready to unleash upon the world, but not upon the official repository
    jim-dev-private - Code that Jim is currently working on from his blimp with irregular Internet access

    fred-dev-public, alice-dev-public, bob-dev-public - These are the only ones that you need to pull from. Fred, Alice, and Bob can have as many private repositories as they'd like, and will share their work when it's ready.

  26. complexity by XO · · Score: 2, Informative

    The complexity of git robs it of quite a bit of the value of it's features. For God only knows what reason, a 5-6 person project that i'm working on is using git instead of subversion, and only the person who setup the project actually has any idea how to use git. The rest of us are just cruising along, not really having any idea of what we are doing with it, and are stopped completely whenever it does anything weird.

    It's awesome to have the whole thing where it merges all the changes in a same file together, fairly intelligently, but even the GUI version for Windows has no functional interface for how to deal with conflicts (which should be easily done as a "which bit of code is the proper piece to use here?" instead of jamming diffs into a file. Also, the Windows and Linux versions of GIT have several problems interoperating with each other.

    In short, Git appears to have been designed entirely with features in mind, and not one bit of usability for anyone other than Linus himself. It is a nightmare for people who only have the need for version control and a handful of people working together. It reminds me very, very much of early Linux, before anyone else besides Linus had been hacking on it.

    --
    "Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
  27. Re:How does it work with non-static IPs? by MostAwesomeDude · · Score: 2, Informative

    Take a page out of Freedesktop.org's process. Any user can create and maintain user repositories in their own space. For example, http://cgit.freedesktop.org/~csimpson/mesa is my personal Mesa repo. Then, anybody that wants can pull from there. Very rarely do FD.O people pull and push directly to each other, and I doubt that it happens that way in larger organizations, either.

    --
    ~ C.
  28. Re:Mercurial vs. Git by PSargent · · Score: 2, Informative

    Have they improved branching in hg?

    Bookmarks are what your after and they came in a couple of versions ago.

  29. Re:Meanwhile... by ewhac · · Score: 2, Informative
    We had ClearCase at MOTO. Complete mess. Nobody -- not even the admins -- could explain how it worked or how to use it. It was also supported only on an ancient version of RedHat Enterprise Linux, since it required a binary filesystem blob to support its version-tracking filesystem. If you didn't have exactly the kernel version it was looking for, ClearCase was simply not available to you. (You'd think, given the sums of money involved in procuring and deploying ClearCase, that Rational/IBM would offer a custom build service, where you'd feed them your kernel config and they'd mail you back a filesystem blob compiled for your kernel. But no, that would have made sense...)

    Based on my imperfect reading, I can see two main appeals of ClearCase:

    1. Everything is version-tracked, including the tools and environment variables you used to build the project. Thus, you are supposed to be able to roll your entire development environment forward and backward through time, and exactly reconstruct any project at any point in time. If you're working on a government project with a 15-year service life, I can see this as being very useful.
    2. ClearCase appears to let you mechanize local management hierarchy and policy. If your manager -- and only your manager -- is authorized to commit code changes to the shipping base of code, ClearCase will let you describe that workflow and enforce it for you. For large organizations with a management fetish, this too is a "feature".

    Schwab

    --
    Editor, A1-AAA AmeriCaptions
  30. Re:My usage of Subversion by grumbel · · Score: 2, Informative

    The main advantage of git over subversion for such uses is that git doesn't require a seperate repository, the repository sits right there in the .git/ directory in your projects directory. Doesn't sound like much, but its great convenience factor, since all you have to do to start using git is type 'git init' and you are done, you don't need to create a repository, you don't need to important your existing files and most importantly you can leave your working directory as is. With SVN this same process can get quite annoying, since you basically have to delete your working direcotry and replace it with a SVN checkout and then verify that all your files actually made it into the repository. With git its a single command and you don't have to think about anything, so its much easier and you can just version control any directory you like.