Subversion or Git? Decisions, decisions ….

  9 comments for “Subversion or Git? Decisions, decisions ….

  1. Pingback: Quora
  2. March 6, 2013 at 11:43 pm

    For me GIT on cygwin in windows just makes more sense and FOR ME plus it was easier to set up.

    I used SVN in college and it was similar to GIT but GIT is much more mainstream now. And i think its easier to fix. I would use both. And still have a back up copy on a Amazon bucket maybe.

    • Jack Repenning
      March 12, 2013 at 2:29 pm

      Cool! What is it about GIT/cygwin that particularly fits for you? For example, are you already committed to the cygwin pseudo-Unix environment anyway?

      And what sort of “fixing” were you talking about?

      • March 12, 2013 at 10:57 pm

        If one person commits before pulling new changes then in Git you can easily fix by merging i think. I would say i’ve used WIndows much more in my lifetime. But i prefer the Unix Command line then DOS. T In the MINGW32 window i can easily move to the GIT Repo and then simply type GIT GUI. THen i just do the normal git commits and after i just push through the command line in ming. ITs by far the easiest way i found. Its also the easiest to set up. ON my mac i do it a little different since GIT GUI does not work. ON linux i’m not sure. But my friends on linux do it very similar and its free. If you know of a better solution on windows for GIT then please let me know. For SVN which is what my University tried to teach us, it was hard to set up correctly. But i’ve used GIT professionally and such have more experience with it so i’m sure i’m just biased… :) I really think it would be better for Universities to start teaching SVN or GIT or require the students to use it. It just makes sense to use the tools. Especially when your dog might eat your PC..

        • Jack Repenning
          March 13, 2013 at 9:48 am

          Huh. Interesting example.

          If a team are using git, and one worker commits then pulls other work in, the potential conflicts are generally handled well by git’s automatic merge included in the pull. Problems can arise (you and I both change the same line in incompatible ways), and git’s conflict resolution is roughly like Subversion’s: you get access to the various “before” versions, and (for a text file) the tool’s guess at the merge match-ups (with “conflict markers”). Probably just due to my history, I generally fine the git conflict-marking to be weaker than Subversion’s: much more likely to match up inappropriately, effectively moving stuff around.

          But in contrast, if this team were using Subversion and the same botch occurred … it couldn’t occur! ;-) Subversion requires the “svn update” (analogous to the “git pull”). This is a bit heavy-handed: it does prevent some really horrifying conflict-resolution messes, but such things are pretty rare. And this protection comes at the cost of “speed-braking” every commit, constraining it to these more-cautious rules and slowing operations while svn checks with the repo to see if there’s any risk.

          For this scenario, it seems to me like the comparison works something like this:

          – For the most common cases, git is faster (because local), more flexible (because of all that handy local versioning).
          – For the next-most common case, of merge conflicts that can be resolved automatically, git seems to be slightly better (that is, can automate more kinds of resolutions).
          – But for the quite rare cases where a human needs to make the judgement, git seems weaker: the conflict-marked merged-diff file is more prone to false matches and dumb mistakes, requiring more and more complicated hand edits to reconcile.

          And of course, there’s a lot to be said for being better at the common cases.

          • March 14, 2013 at 10:47 am

            Yes, I think you make an important point that i did not know about. And i’ve seen the problems with GIT you mentioned first hand. Maybe SVN is a better choice in my case. Can you use both?

          • Jack Repenning
            March 14, 2013 at 11:12 am

            It is possible to use both at once. I actually do that, for one of my repositories: I’m thinking of migrating it from SVN to git, so this allows me to compare the two on exactly the same data and operations.

            What I’m doing is to commit every change into both repositories. The two tools play with each other pretty well — for example, each knows not to try to version the other’s admin directories.

            Some people have used git for local work, and SVN to promote changes to a group directory (gaining the personal flexibilities of local versioning, while retaining the enforcement and auditability of a central repository). There’s even a plugin for git, git-svn, that includes support for this model.

            But I don’t think anything like either of these helps the merge-conflict situation any … rather the opposite: one way or another, you have to satisfy both systems. If anything, using them both makes it more likely you run into a rough spot of one or the other tool.

  3. LiuYan 刘研
    August 15, 2014 at 1:13 am

    maybe offtopic: i really like the serial version numbering of each file in CVS. SVN and GIT does not have a version number for a single file. Version numbering in SVN is better than GIT for me, because it’s decimal number, each for human reading/remembering than the “random” hex string version number in GIT. (sorry for my English)

Leave a Reply

Your email address will not be published. Required fields are marked *