Git vs. SVN and what NOT to do...



  • So I left my last Enterprisy-esque job to join a small startup. When I was first hired, we only had four employees and one contractor; the office manager is semi-retired, and only works a few days a week. The guy that I replaced had only been here for a couple of months, and left because he found a "better" job. During the "hand-off", he was telling me about his "best practices", which included using Git as the version control system. Every Git command that he showed me - I have never used Git, and am more accustomed to Subversion - I would ask what each flag did for the command (i.e., "git commit -a"). His response to those questions? "I don't know, that's just what I found on Stackoverflow.com." Okay, no problem; he's an idiot. I'll just move the Git repositories back to Subversion the first chance that I get. After all, I am more familiar with Subversion, I have little interest in re-learning a new version control system, and there are no real immediate or long term benefits to staying with Git.

    Fast forward a week or two, when I finally get an opportunity to move everything back into Subversion. After a few minutes of reading the man pages, and reading several blog posts across the Interwebs, I gathered enough information to begin the arduous process of moving the Git history into a fresh Subversion repository. After setting up Git to be linked to the new repository and issuing the command to sync everything up (and waiting the 45 minutes or so that it took to import the Git history into Subversion), I happily checked out the Subversion repository only to find out that Subversion doesn't like it when you have committed .svn folders everywhere - not that I blame Subversion for that, since those folders are not supposed to be stored physically in the repository to begin with. So, long story short: the idiot who decided on a whim to switch from Subversion to Git had the great idea of just blindly committing every single Subversion file as his means of retaining a commit history. Now I'm stuck with Git until I can find even more time to try to undo his huge WTF.

    PS. If anybody has suggestions for how to get Git to commit back to Subversion, without the .svn folders, I would be more than happy to buy you beers as a thank you!



  • @dohpaz42 said:

    PS. If anybody has suggestions for how to get Git to commit back to Subversion, without the .svn folders,...
    Is there no equivalent in git for
    find . | grep .svn | xargs svn rm; svn ci -m "removed svn metadata"
    then perform your 45 minute transfer again (though it's likely to be a lot less since it won't be transferring all the .svn stuff)?



  • You could probably just check out the source with git, delete the svn directories, commt (must be done before the next step to see the deletion), add an entry to .gitignore (to ignore .svn directories in the future), then commit again.

    Also I'd recommend just learning Git. It's leagues better than subversion for many, many reasons (most modern source control systems are imo)



  • @PJH said:

    @dohpaz42 said:
    PS. If anybody has suggestions for how to get Git to commit back to Subversion, without the .svn folders, I would be more than happy to buy you beers as a thank you!
    Is there no equivalent in git for
    find . | grep .svn | xargs svn rm; svn ci -m "removed svn metatdata"
    ?

    Unfortunately if you delete the .svn folders from the filesystem, then you've just broken your checkout and cannot commit back to the repository. So far, my best guess is that I would have to write a script that looks at a checked out repository and make remote calls to the Subversion server to remove them directory from the repository. However, that would be more time consuming than I have available right now, and I am not sure if that really would work. Plus, ideally, I'd like to somehow get the old version history pre-Git and load it into the fresh repository, then somehow merge in the Git history, and then start from there.



  • @KallDrexx said:

    You could probably just check out the source with git, delete the svn directories, commt (must be done before the next step to see the deletion), add an entry to .gitignore (to ignore .svn directories in the future), then commit again.

    Also I'd recommend just learning Git. It's leagues better than subversion for many, many reasons (most modern source control systems are imo)

    That's been done already; removing the .svn folders from Git, and ignoring .svn folders in .gitignore. Unfortunately, because the .svn are a part of the history up until a certain point, it still breaks Subversion when it has to replay the entire history.



  • Is there any reason why you're not willing to learn a new repository? I'm sure the time it takes to figure this clusterfuck up (and train your group on how to use SVN) would take just as much time as simply learning Git. If it's like other source control the learning curve shouldn't be steep.

    I don't have any first-hand experience with Git but from what I've heard second-hand from friends who do, Git's much easier to merge branches with. I find that dubious, though, because there are tons of SVN clients which provide probably the same merging tools that Git provides natively. That being said, the folks who have told me this are generally competent engineers so there might be some validity to what they're saying. Basically, they consider Git to be to Subversion what Subversion was to CVS.

    What I predict's going to happen with you is, as you procrastinate moving Git to SVN and inevitably learn how Git works, you might actually become accustomed to Git and abandon all your plans to migrate it back to SVN. Just an uneducated guess, though.

    Nevertheless, no matter what you do, I strongly suggest you remove those .svn directories from Git's repository to avoid any future confusion. :-)



  • @dohpaz42 said:

    @PJH said:
    @dohpaz42 said:
    PS. If anybody has suggestions for how to get Git to commit back to Subversion, without the .svn folders, I would be more than happy to buy you beers as a thank you!
    Is there no equivalent in git for
    find . | grep .svn | xargs svn rm; svn ci -m "removed svn metatdata"
    ?
    Unfortunately if you delete the .svn folders from the filesystem, then you've just broken your checkout and cannot commit back to the repository.
    I think you misunderstood me - I meant you need to remove the .svn folders while you've got git checked out, not while you have svn checked out.:

    1. Check out in git
    2. Delete .svn
    3. Check back into git
    4. Transfer to svn
    5. Check out svn


  • @dohpaz42 said:

    removing the .svn folders from Git, and ignoring .svn folders in .gitignore. Unfortunately, because the .svn are a part of the history up until a certain point, it still breaks Subversion when it has to replay the entire history.
    Ah - that spikes my suggestion then. Ignore it.



  • @RHuckster said:

    Is there any reason why you're not willing to learn a new repository? I'm sure the time it takes to figure this clusterfuck up (and train your group on how to use SVN) would take just as much time as simply learning Git. If it's like other source control the learning curve shouldn't be steep.

    I don't have any first-hand experience with Git but from what I've heard second-hand from friends who do, Git's much easier to merge branches with. I find that dubious, though, because there are tons of SVN clients which provide probably the same merging tools that Git provides natively. That being said, the folks who have told me this are generally competent engineers so there might be some validity to what they're saying. Basically, they consider Git to be to Subversion what Subversion was to CVS.

    What I predict's going to happen with you is, as you procrastinate moving Git to SVN and inevitably learn how Git works, you might actually become accustomed to Git and abandon all your plans to migrate it back to SVN. Just an uneducated guess, though.

    Nevertheless, no matter what you do, I strongly suggest you remove those .svn directories from Git's repository to avoid any future confusion. :-)

    I'm not against learning and using a new technology. However, there are less savvy persons (i.e., designers) who will need to be able to use source control, and I've found through experience that they tend to do better with Subversion; so far, it's been a huge PITA trying to explain Git to them, because Git seems to have a more complex workflow than Subversion has. But you're right; through procrastination, I've learned a lot about using Git.



  • Just enable the "_svn hack".  That makes the .svn directory non-special.

     [url="http://svn.apache.org/repos/asf/subversion/trunk/notes/asp-dot-net-hack.txt"]_svn hack[/url]



  •  @dohpaz42 said:

    PS. If anybody has suggestions for how to get Git to commit back to Subversion, without the .svn folders, I would be more than happy to buy you beers as a thank you!

    Not tested, but I think you should be able to create a new, empty, git repository, git-cherry-pick -n the original import into git, delete the .svn folders, commit, and then cherry-pick all the subsequent commits. That would get you a git repository with no record of the .svn folders, so you should then be able to apply your known method for importing into svn.



  • @Jaime said:

    Just enable the "_svn hack".  That makes the .svn directory non-special.

     _svn hack

    @pjt33 said:

     [quote user="dohpaz42"]PS. If anybody has suggestions for how to get Git to commit back to Subversion, without the .svn folders, I would be more than happy to buy you beers as a thank you!

    Not tested, but I think you should be able to create a new, empty, git repository, git-cherry-pick -n the original import into git, delete the .svn folders, commit, and then cherry-pick all the subsequent commits. That would get you a git repository with no record of the .svn folders, so you should then be able to apply your known method for importing into svn.

    [/quote]

    Thanks! I will definitely try both of those suggestions.



  • svndumpfilter exclude could be useful.



  • If the .svn files have all been committed in a single revision and never touched again later, you can fix it with svn alone:

    Take your repository and svnadmin dump --incremental it into three dump files: One up to the faulty revision, one for the faulty revision only, one for the rest.

    svn export the faulty revision from the old repository (I never tested it, but I think export should work even without _svn hack enabled). Delete all .svn dirs from it.

    Take a shiny new repository and svnadmin load the first dump file into it. Check it out, copy the faulty revision over it, and recommit it (you might have to manually svn add/delete files, depending on what was in that revision). Enable pre-revprop-change-hook (just return true), and use your favourite svn client to edit the rev properties (especially author and date) of the faulty commit (the revision number should already be right). Disable pre-revprop-change-hook again (ok you can leave it on if you don't mind if anyone tries to "rewrite history"), and svnadmin load the last dump file into it. If any of the revisions tries to change one of the .svn files or you forgot some files or committed incorrect ones (so that the diffs do not apply), you will get an error now. If not, you have a shiny new repo like you like it :)

    Alternatively you can try to filter the second dump file and try if you get all the .svn things out, then just load all three dump files.

    HTH,

    mihi



  • Git has a tool for this. It's called filter-branch. For example:



    git filter-branch --index-filter 'git rm --cached --ignore-unmatch .svn' HEAD



    As seen here: http://help.github.com/remove-sensitive-data/



    That will replay the entire history of the current branch, removing anything named .svn from each commit. It will change the commit hashes. It won't delete the actual .svn dirs in the working copy.



    You should be able to retain all the history as well, using a couple of branches and a rebase. Convert the original SVN history into a new git branch, svnhist. Then rebase:



    git checkout master


    git rebase svnhist



    That will replay all the history of master on top of the svnhist branch. Assuming the original git commit was identical to where the SVN history ended, there shouldn't even be any merge conflicts.



    Then you can import the full history back to SVN. Even though SVN sucks. :)



  • @dohpaz42 said:

    After all, I am more familiar with Subversion, I have little interest in re-learning a new version control system, and there are no real immediate or long term benefits to staying with Git.

    @dohpaz42 said:

    PS. If anybody has suggestions for how to get Git to commit back to Subversion, without the .svn folders, I would be more than happy to buy you beers as a thank you!

    The SVN folder pollution alone are a good reason to be using anything but Subversion. If you're not doing anything wacky like rebasing or whatever, then GIT should feel almost identical to SVN but with the extra push/pull commands to sync your local repo to the server's repo. Considering how much better distributed version control systems branch and merge, I'd say grit your teeth and take a day to learn GIT or Mercurial since it'll save your ass later on. As far as the flags, they're in the command line help.



  • @superjer said:

    Git has a tool for this. It's called filter-branch. For example:



    git filter-branch --index-filter 'git rm --cached --ignore-unmatch .svn' HEAD



    As seen here: http://help.github.com/remove-sensitive-data/



    That will replay the entire history of the current branch, removing anything named .svn from each commit. It will change the commit hashes. It won't delete the actual .svn dirs in the working copy.



    You should be able to retain all the history as well, using a couple of branches and a rebase. Convert the original SVN history into a new git branch, svnhist. Then rebase:



    git checkout master


    git rebase svnhist



    That will replay all the history of master on top of the svnhist branch. Assuming the original git commit was identical to where the SVN history ended, there shouldn't even be any merge conflicts.



    Then you can import the full history back to SVN. Even though SVN sucks. :)

    There's this odd little voice in the back of my head suggesting that the fact that recovering from this with history intact AND switching back to svn is an argument in favor of git being overall better than subversion, and that the fact that it took this many posts before we got someone who knew it could be this easy is an argument in favor of not trying to teach git to people who have a hard time getting the hang of new things.

    (That said, I like git better than svn myself, although due to how I have to be able to do things at work I know Bazaar and Mercurial better and mostly use Mercurial.)



  • @kilroo said:

    There's this odd little voice in the back of my head suggesting that the fact that recovering from this with history intact AND switching back to svn is an argument in favor of git being overall better than subversion, and that the fact that it took this many posts before we got someone who knew it could be this easy is an argument in favor of not trying to teach git to people who have a hard time getting the hang of new things.

    (That said, I like git better than svn myself, although due to how I have to be able to do things at work I know Bazaar and Mercurial better and mostly use Mercurial.)

    I suppose you also say that we should all stick to Basic and COBOL since all those things you can do with modern programming languages are just to hard to teach to the simple folk?



  • @dtech said:

    I suppose you also say that we should all stick to Basic and COBOL since all those things you can do with modern programming languages are just to hard to teach to the simple folk?

    The existence of this site says that it doesn't really matter. They're still gonna fuck it up.



  • @Soviut said:

    The SVN folder pollution alone are a good reason to be using anything but Subversion.
    This goes away in 1.7, currently in beta. There is only one .svn dir, at the top of the working copy. Really, the number one reason for using svn, for Windows users, is TortoiseSVN.



  • @Sir Twist said:

    This goes away in 1.7, currently in beta. There is only one .svn dir, at the top of the working copy. Really, the number one reason for using svn, for Windows users, is TortoiseSVN.

    Finally!

    @Sir Twist said:

    Really, the number one reason for using svn, for Windows users, is TortoiseSVN.

    I hate TortoiseSVN. And all the other tortoise versions of SCM tools.



  • @Sir Twist said:

    @Soviut said:

    The SVN folder pollution alone are a good reason to be using anything but Subversion.
    This goes away in 1.7, currently in beta. There is only one .svn dir, at the top of the working copy. Really, the number one reason for using svn, for Windows users, is TortoiseSVN.

    Great, that only took, what? 11 years?

    Moving things from GIT to SVN seems like going backwards. Like moving everything from SVN to CVS just because you "know CVS better" and "don't see any benefit to SVN".



  • Well, I moved this company from VSS to SVN. It's all Windows, Windows development, or Windows tools for embedded development. There was no git at the time. Nobody else would put up with having to use a command line for source control anyway.



  • I made some errors!



    You'll need to use rm -r instead of just rm or git will refuse to remove .svn since it's a directory. It will tell you exactly that if you try to run it as I said originally, and then do nothing.



    Also it appears that it will actually delete the working copy's .svn dirs. For some reason I thought filter-branch only operated on the cache.



  • @Sir Twist said:

    Well, I moved this company from VSS to SVN. It's all Windows, Windows development, or Windows tools for embedded development. There was no git at the time. Nobody else would put up with having to use a command line for source control anyway.

    I've relatively recently converted to using Mercurial, which is a DVCS as well, and it hurts to use svn (which I still do at work). There is a tortoise client for mercurial.


  • Discourse touched me in a no-no place

    @boomzilla said:

    @Sir Twist said:
    Well, I moved this company from VSS to SVN. It's all Windows, Windows development, or Windows tools for embedded development. There was no git at the time. Nobody else would put up with having to use a command line for source control anyway.

    I've relatively recently converted to using Mercurial, which is a DVCS as well, and it hurts to use svn (which I still do at work). There is a tortoise client for mercurial.

    There's also one that integrates into Visual Studio. I still prefer SVN, though, for workflow reasons that are too complicated for me to give a damn about going into.



  • Bad move. It uses Git, so learn Git. If you have compelling reasons to move back to SVN after having learned and got used to Git, then go to it. But you will probably find, after you've learned Git, that you won't want to. The problem there is the learning curve.



  • Well, I was checking out the free DVCS systems three years ago or so. Some were annoying, some I just didn't like... Git I consider to be one of the "unnecessarily complicated to look powerful" pieces of software. Anyway, after initial selection I've tested git, bazaar, and mercurial on a few toy projects. I find mercurial to be the most pleasant and easy to use out of all of them. I dunno, maybe with projects of the scale and magnitude of distrubution of the linux kernel git has plausible reasons to be better. But just like you don't buy Oracle (and hire consultants) where Postgres or MySQL would suffice, you don't go for additional pains where there's no justification.


  • Discourse touched me in a no-no place

     I take exception to your " In 99% cases MSSQL > Oracle" tag. (TRWTF is that that copypasted as a hyperlink)

    What, exactly, sits in the other 1%? People say shit like that all the time, and I've never once managed to get a readback on exactly what that 1% application must look like.



  • @Matt Westwood said:

    Bad move. It uses Git, so learn Git. If you have compelling reasons to move back to SVN after having learned and got used to Git, then go to it. But you will probably find, after you've learned Git, that you won't want to. The problem there is the learning curve.

    If the learning curve is bad, the product is bad. Stick that in your pipe and smoke it!!



  • @blakeyrat said:

    @Matt Westwood said:
    Bad move. It uses Git, so learn Git. If you have compelling reasons to move back to SVN after having learned and got used to Git, then go to it. But you will probably find, after you've learned Git, that you won't want to. The problem there is the learning curve.

    If the learning curve is bad, the product is bad. Stick that in your pipe and smoke it!!

    I haven't done much more than play with git. The model for how a centralized VCS, like subversion, works is pretty simple. And if you've been working with that model a lot, it can be difficult to shift over to using a DVCS, even though the model truly isn't so different. But getting to the point where you "get" that shift can be pretty difficult. But in the case of DVCS, totally worth it.

    A lot of the commands and what-not for git that I see seem fairly arcane, but then again, that's probably my unfamiliarity with the tool. Doing anything complicated with some set of data is usually not obvious, whatever tool you're using. With VCS, though, the initial use cases are usually pretty simple, so you can slowly build up the arcane side as you come across the need. You don't need to be at the top of the curve before you can be productive.



  • @Weng said:

    What, exactly, sits in the other 1%? People say shit like that all the time, and I've never once managed to get a readback on exactly what that 1% application must look like.

    I don't claim to know everything, so benefit of a doubt makes me say that some cases (multipetabyte datasets under specific patterns?) it actually is better than MSSQL.
    "You don't need Oracle, no, even if you think you do" is the answer if you're the application maker. Now, of course, there's a crapton and even more of software that depends on Oracle to feel enterprisey and have a justification to rack up the price. But seriously, after working with it and learning a bit about the internals, I can't use any comparison lighter than "paying extra to get something more screwed up".

    I'm afraid it's not really an answer to your question; thing is, I can't imagine myself an app that'd need Oracle's "performance", especially as I'm not convinced it actually is better in this regard. It's all just "good marketing point" and "being locked in into that particular flavor of SQL".

    @boomzilla said:

    A lot of the commands and what-not for git that I see seem fairly arcane, but then again, that's probably my unfamiliarity with the tool. Doing anything complicated with some set of data is usually not obvious, whatever tool you're using. With VCS, though, the initial use cases are usually pretty simple, so you can slowly build up the arcane side as you come across the need. You don't need to be at the top of the curve before you can be productive.

    Just for kicks, try mercurial. Or, for Something Completely Different, darcs. I'm pretty sure you'll find at least one of the two much more intuitive.

    It feels odd to agree with blakey, but yes, git feels much more user-hostile than most other DVCSes. Yes, I'm comparing the commandline apps.



  • @dohpaz42 said:

    I have never used Git, and am more accustomed to Subversion  [ ... ] Okay, no problem; he's an idiot. I'll just move the Git repositories back to Subversion the first chance that I get. After all, I am more familiar with Subversion, I have little interest in re-learning a new version control system, and there are no real immediate or long term benefits to staying with Git.

    Okay, no problem, you're an idiot too.  "I don't understand it" is actually not the same as "It is worthless", but it's a common fallacy committed by idiots.  There are very real immediate and long-term benefits to learning how to use it, you simply don't know what they are because you have a closed mind and are convinced you know without trying.

    I bothered to spend a couple of days learning how to use git after having been used to svn for many years.  It was easy.  Of course you have to be willing to learn new things and not emotionally attached to always doing things the same way you have done before.



  • @blakeyrat said:

    @Matt Westwood said:
    Bad move. It uses Git, so learn Git. If you have compelling reasons to move back to SVN after having learned and got used to Git, then go to it. But you will probably find, after you've learned Git, that you won't want to. The problem there is the learning curve.

    If the learning curve is bad, the product is bad. Stick that in your pipe and smoke it!!

    But can you explain why we should trust the OP's estimation of the learning curve?  It seemed pretty likely to me that that evaluation suffered from being based on a pre-judged conclusion made without the benefit of any actual experience.




  • @DaveK said:

    But can you explain why we should trust the OP's estimation of the learning curve?

    Well, I haven't seen a source control product yet without a horribly shitty learning curve. Unless you count something like Apple's "Time Machine" or Word's "Track Changes" features source control.

    @DaveK said:

    It seemed pretty likely to me that that evaluation suffered from being based on a pre-judged conclusion made without the benefit of any actual experience.

    It helps to remember everybody here is a troll.



  • @bannedfromcoding said:

    @boomzilla said:
    A lot of the commands and what-not for git that I see seem fairly arcane, but then again, that's probably my unfamiliarity with the tool. Doing anything complicated with some set of data is usually not obvious, whatever tool you're using. With VCS, though, the initial use cases are usually pretty simple, so you can slowly build up the arcane side as you come across the need. You don't need to be at the top of the curve before you can be productive.

    Just for kicks, try mercurial. Or, for Something Completely Different, darcs. I'm pretty sure you'll find at least one of the two much more intuitive.

    I think you misunderstood what I was saying. It didn't take me very long to pick up on how it worked, but I've seen a lot of people struggle with it. Also, as I mentioned above, mercurial is currently my "default" version control of choice. I just literally haven't spent more than a few minutes with git.



  • @DaveK said:

    @dohpaz42 said:

    I have never used Git, and am more accustomed to Subversion  [ ... ] Okay, no problem; he's an idiot. I'll just move the Git repositories back to Subversion the first chance that I get. After all, I am more familiar with Subversion, I have little interest in re-learning a new version control system, and there are no real immediate or long term benefits to staying with Git.

    Okay, no problem, you're an idiot too.  "I don't understand it" is actually not the same as "It is worthless", but it's a common fallacy committed by idiots.  There are very real immediate and long-term benefits to learning how to use it, you simply don't know what they are because you have a closed mind and are convinced you know without trying.

    I bothered to spend a couple of days learning how to use git after having been used to svn for many years.  It was easy.  Of course you have to be willing to learn new things and not emotionally attached to always doing things the same way you have done before.

    Okay, I'll byte. First off, I never said that it is worthless. I said that it doesn't fit with the work that I'm doing. I don't believe in change for the sake of change. Subversion works well for my, and my company's needs. In fact, Subversion is a better fit because it has a lower learning curve for non tech-savvy people. I've said this already. What I didn't say is that Subversion also has GUI tools, specifically for Eclipse. Harp on that all you want, but my productivity over the past two months of using Git has gone down in comparison to the same amount of work that I could do so much more efficiently with Subversion. I, as a single developer, have little need for "distributed" version control. My designer is not a command-line guy (what designer is?). Every time I help him learn something new with Git (I haven't even dared to suggest branching with him), I have to waste 10 minutes every hour re-explaining concepts to him. Harp on that all you will, but he has less interest in learning command line tools than I do learning Git.

    Out of every single person who says "Git is better than Subversion", not one of them has said why. It's distributed. Big deal. So I have to commit twice (once locally, and once to the remote). Yeah, I get that it's decentralized. I prefer a centralized server. Oh, there's Github; it costs $12/month. Sure that's not a lot of money, but then again it still costs more than Subversion. So with that said, put your money where your mouth is: re-read my original post, then explain to me these "very real immediate and long-term benefits" for me spending my precious time learning a complex new piece of software that is nothing more than overkill.



  • @blakeyrat said:

    @Matt Westwood said:
    Bad move. It uses Git, so learn Git. If you have compelling reasons to move back to SVN after having learned and got used to Git, then go to it. But you will probably find, after you've learned Git, that you won't want to. The problem there is the learning curve.

    If the learning curve is bad, the product is bad. Stick that in your pipe and smoke it!!

    Then I guess SVN is bad and nobody should use source control since they all require some form of learning curve. Better the endless pain and toiling of using zip files with dates for names, because, you know, everyone gets that.

    PS: I know you were probably being facetious, but so was i ;)



  • @Matt Westwood said:

    The problem there is the learning curve.

    The problem is motivation. Why learn Yet Another Program™ to do the same thing, just slightly differently? There must be a compelling (but not necessarily rational) reason or it is just a waste of time. And by that I mean it feels like a waste of time, which is a lot worse. Remember that utterly boring and useless class at school you had to attend? Same feeling.



  • @fatbull said:

    @Matt Westwood said:

    The problem there is the learning curve.

    The problem is motivation. Why learn Yet Another Program™ to do the same thing, just slightly differently? There must be a compelling (but not necessarily rational) reason or it is just a waste of time. And by that I mean it feels like a waste of time, which is a lot worse. Remember that utterly boring and useless class at school you had to attend? Same feeling.


    I'd say that when one develops a severe aversion to learning anything, it might be time to check out at the local suicide booth. This isn't even completely useless shit like literary analysis.



  • @dohpaz42 said:

    Out of every single person who says "Git is better than Subversion", not one of them has said why. It's distributed. Big deal. So I have to commit twice (once locally, and once to the remote). Yeah, I get that it's decentralized. I prefer a centralized server.

    The benefits are less for a single person, though, you have at least some other people working in your repository. One of the benefits, which isn't really obvious at first, coming from a centralized VCS, is that there are no implicit merges in DVCS. For instance, in svn, if two people work on the same file, and one commits, then the other one will have to update his working copy, thus merging the other developer's changes with his own, before he can commit. Also, you will get any other changes he's made.

    With a DVCS, any changes at all effectively creates a separate branch. So if two people do their own changes, even if on completely separate files, it requires a merge. On the one hand, this requires a bit more work, because you have to actually do the merge. On the other hand, it's actually safer. I'm sure we've all had times where some change somewhere that someone else did affected something in another part of the system that we were changing or working with or whatever. By forcing an explicit merge, it's easier to find and track these problems.

    If you had this situation while using svn, you might not notice it, or you'd update prior to your commit, and suddenly find you had a problem which you have to fix before you can commit (assuming you don't want to make a broken commit). In a DVCS, you'd have to merge the branches, so you're more likely to notice this sort of thing and it's generally easier to figure out what's going on. Also, you can be assured that whatever anyone else is doing, it won't affect your local work, at least until you're ready to merge.



  • @Mo6eB said:

    @fatbull said:

    @Matt Westwood said:

    The problem there is the learning curve.

    The problem is motivation. Why learn Yet Another Program™ to do the same thing, just slightly differently? There must be a compelling (but not necessarily rational) reason or it is just a waste of time. And by that I mean it feels like a waste of time, which is a lot worse. Remember that utterly boring and useless class at school you had to attend? Same feeling.


    I'd say that when one develops a severe aversion to learning anything, it might be time to check out at the local suicide booth. This isn't even completely useless shit like literary analysis.

    More to the point is that the predecessor who switched to Git from svn in the first place must have had a good reason to do so, and I won't accept "he was an idiot" as an excuse. The decision was made, for better or for worse, and until you know your way around Git, you won't be sufficiently informed as to understand why.

    (While I'm about it, in the words of (I believe) George Carlin: "Anybody who drives slower than you is an idiot, and anyone who drives faster than you is a maniac." In the computer industry, that equates to: "Anyone who prefers to use a different tool from the one you prefer is an idiot, and anyone who chooses to write in a different language is a maniac.")

    Once you have got your head round Git (and in the meantime you will have programmed some neat little tools to help out the designers whose job it isn't to learn Git) you will be in a position to present a case for going back to svn. On the other hand, if you break the entire system by going back to svn now before you really learn what's going on, [b]you're[/b] the idiot. No, what you are is a [b]maniac[/b].


  • Discourse touched me in a no-no place

    @boomzilla said:

    The benefits are less for a single person, though, you have at least some other people working in your repository. One of the benefits, which isn't really obvious at first, coming from a centralized VCS, is that there are no implicit merges in DVCS. For instance, in svn, if two people work on the same file, and one commits, then the other one will have to update his working copy, thus merging the other developer's changes with his own, before he can commit. Also, you will get any other changes he's made.

    With a DVCS, any changes at all effectively creates a separate branch. So if two people do their own changes, even if on completely separate files, it requires a merge. On the one hand, this requires a bit more work, because you have to actually do the merge. On the other hand, it's actually safer. I'm sure we've all had times where some change somewhere that someone else did affected something in another part of the system that we were changing or working with or whatever. By forcing an explicit merge, it's easier to find and track these problems.

    However, it completely blows up the following scenario, which I run into FAR more often than two people making conflicting changes to the same file (if you manage to see the merge screen often, chances are good that either your architecture or your division of labor could use some work). 

    Dev A is working on widget.cs. Dev B is working on Form2.cs and is the expert on the very complicated superWidget.cs
    Dev A: "Can you fix superWidget to do this other thing that I need it do do?"
    Dev B: "Sure"

    At this point, Dev B, using SVN or similar, pops over to his checkout of superWidget, makes the change, and commits it. With a DVCS, he either has to clone Dev A's branch repository (which likely isn't possible on a heavily firewalled corporate network) or make the changes in his branch and merge those changes in - but those changes don't make semantic sense in his branch.

    In short, a DVCS is well suited to One Feature, One Programmer teams - which is to say the most informal cowboy-coder environments and the most formal ones. A more traditional VCS is likely better for that middleground with a handful of people working extremely closely. 



  • @Weng said:

    However, it completely blows up the following scenario, which I run into FAR more often than two people making conflicting changes to the same file (if you manage to see the merge screen often, chances are good that either your architecture or your division of labor could use some work). 

    Dev A is working on widget.cs. Dev B is working on Form2.cs and is the expert on the very complicated superWidget.cs

    I think you've confused "completely blows up" with, "can be a little more work, but is ultimately cleaner and safer."

    @Weng said:

    Dev A: "Can you fix superWidget to do this other thing that I need it do do?"

    Dev B: "Sure"

    At this point, Dev B, using SVN or similar, pops over to his checkout of superWidget, makes the change, and commits it. With a DVCS, he either has to clone Dev A's branch repository (which likely isn't possible on a heavily firewalled corporate network) or make the changes in his branch and merge those changes in - but those changes don't make semantic sense in his branch.

    If a "heavily firewalled corporate environment" makes getting someone else's code difficult, I cannot fathom how a centralized VCS would get around it. Or...how would you ever build anything to go to testing or release? Either way, you're right that B wouldn't want to make those changes in his branch, either with or without svn. So, either you're all working on the same svn branch (which is pretty common, really) or you have the same issue of switching to A's branch.

    @Weng said:


    In short, a DVCS is well suited to One Feature, One Programmer teams - which is to say the most informal cowboy-coder environments and the most formal ones. A more traditional VCS is likely better for that middleground with a handful of people working extremely closely.

    You've gotten it all backwards. The DVCS is much better suited to a handful (or more) of people working together. It keeps them from accidentally stepping on each others' progress and enforces that everyone works on different branches. The basic DVCS workflow comes down to:

    1. Pull in changes from others and update your working copy.
    2. Make your changes and commit to your local repo.
    3. If others have pushed anything new, you can then pull their changes in and merge with yours. (Sometimes this step is only done by a particular person.)
    4. Push your changes out so others can get them.

    The key here is that your work can proceed from 1 to 2 without worrying about others committing code, requiring you to merge your changes with theirs. I'm sure we've all been told by svn that our working copy is out of date (unless your team is super disciplined, and everyone develops in a separate branch). You don't have to worry about merging until you've made all of your changes and are ready to merge. Merging an update from the repo with svn can wipe out some of your work, and it's not always easy to get it back.

    Obviously, if you don't have people working simultaneously, then work ends up serialized, and the end result looks very similar to what you'd get with svn.



  • @Weng said:

    In short, a DVCS is well suited to One Feature, One Programmer teams - which is to say the most informal cowboy-coder environments and the most formal ones. A more traditional VCS is likely better for that middleground with a handful of people working extremely closely.

    This is the exactly the opposite. Centralized version control has the old "commit and subject" paradigm, where everyone is instantly subjected to your change once you've committed it. If it causes a breakage, your entire team is down while it gets sorted out, and usually requires everyone be in the same room to make that work. Often you hear people saying "whatever you do, don't update right now". It has the effect of causing people to be so scared of commits that they only do one once a week; They essentially stop versioning their code, defeating the whole purpose.

    DVSC was specifically designed for teams, where individuals and groups may need to experiment and branch. Meanwhile, SVN branching was an afterthought. It rarely works, and usually involves a massive manual process where all the developers have to be physically present to make sure it worked.



  • @Soviut said:

    This is the exactly the opposite. Centralized version control has the old "commit and subject" paradigm, where everyone is instantly subjected to your change once you've committed it.

    This is what branching is for. What I've found in my experience is that people don't fully understand how to use Subversion, and they cause the majority of their problems, not Subversion. But, the same thing could be said for any complex software, such as Git.

    @Soviut said:

    f it causes a breakage, your entire team is down while it gets sorted out, and usually requires everyone be in the same room to make that work. Often you hear people saying "whatever you do, don't update right now". It has the effect of causing people to be so scared of commits that they only do one once a week; They essentially stop versioning their code, defeating the whole purpose.

    You can easily roll back to a previously-working revision until the breakage gets fixed.

    @Soviut said:

    DVSC was specifically designed for teams, where individuals and groups may need to experiment and branch. Meanwhile, SVN branching was an afterthought. It rarely works, and usually involves a massive manual process where all the developers have to be physically present to make sure it worked.

    I have done my homework on Git, and that is one of its pluses; being able to work locally with multiple changesets before pushing it back into the remote for everyone to pick up. However, one thing that I've found that I dislike is that if someone who doesn't understand conflicts, or how to properly resolve them, Git will allow you to commit the conflict back into the repo. Subversion will not let you commit until the conflict has been resolved.

    If Git's GUI was as mature as Subversion's is, I probably would make the move. However, I cannot in good conscience do this, because not all of the team members have the technical capacity to properly use the software.



  • @dohpaz42 said:

    I have done my homework on Git, and that is one of its pluses; being able to work locally with multiple changesets before pushing it back into the remote for everyone to pick up. However, one thing that I've found that I dislike is that if someone who doesn't understand conflicts, or how to properly resolve them, Git will allow you to commit the conflict back into the repo. Subversion will not let you commit until the conflict has been resolved.

    I actually am not as familiar with GIT, but I know Mercurial won't let you push the changes until you've pull the latest version of the repo and merged your changes locally.

    @dohpaz42 said:

    If Git's GUI was as mature as Subversion's is, I probably would make the move. However, I cannot in good conscience do this, because not all of the team members have the technical capacity to properly use the software.

    I teach a Flash game scripting class to students in a Game Development course. Despite the name, the course primarily focuses on the art side of games; modelling, texturing, getting it all into UDK, etc. These students are not developers. Yet I was able to get them all up to speed with Mercurial so they could build (simple) games in groups of three. All of this from the command line and on Windows machines. This was an entire class of artists who learned Mercurial in a few weeks on top of learning how to code from scratch.

    I'm not saying there isn't a learning curve, but it isn't like SVN is much simpler than a distributed version control system. Really, the only difference is being able to push and pull between repos.



  • @Soviut said:

    @dohpaz42 said:

    I have done my homework on Git, and that is one of its pluses; being able to work locally with multiple changesets before pushing it back into the remote for everyone to pick up. However, one thing that I've found that I dislike is that if someone who doesn't understand conflicts, or how to properly resolve them, Git will allow you to commit the conflict back into the repo. Subversion will not let you commit until the conflict has been resolved.

    I actually am not as familiar with GIT, but I know Mercurial won't let you push the changes until you've pull the latest version of the repo and merged your changes locally.

    In mercurial, you can push your changes without merging, but you have to use the --force flag.



  • @blakeyrat said:

    @DaveK said:
    But can you explain why we should trust the OP's estimation of the learning curve?

    Well, I haven't seen a source control product yet without a horribly shitty learning curve. Unless you count something like Apple's "Time Machine" or Word's "Track Changes" features source control.

    Well, learning how to use new technology, techniques and tools is really very much part of our job as developers, I don't think "having to learn it" is a good reason not to use something that has a lot of other benefits.

    @blakeyrat said:

    @DaveK said:
    It seemed pretty likely to me that that evaluation suffered from being based on a pre-judged conclusion made without the benefit of any actual experience.

    It helps to remember everybody here is a troll.

    Backatcha ;-)

     



  • @DaveK said:

    @blakeyrat said:
    @DaveK said:
    But can you explain why we should trust the OP's estimation of the learning curve?

    Well, I haven't seen a source control product yet without a horribly shitty learning curve. Unless you count something like Apple's "Time Machine" or Word's "Track Changes" features source control.

    Well, learning how to use new technology, techniques and tools is really very much part of our job as developers, I don't think "having to learn it" is a good reason not to use something that has a lot of other benefits.

    Yah, but "learning curve" is a factor of the program. So if it's a "great" program, but it has a shitty learning curve, then it's not really all that great a program, is it? It has to be great in all aspects to be great.

    There's this tacit assumption among programmers that if it's a programming tool, usability doesn't matter. Every so often you find a team that says, "fuck that belief" and makes something really, really great-- like the first Forms editor in VB, or HyperCard, or SQL Server Query Analyzer. So fuck that belief.

    If nothing else, the existence and popularity of the "Track Changes" feature in Word shows that people would love to use source control for all types of files, and the main reason they don't is because source control systems are all too fucking difficult. If my mom can't figure out how to use Git to track revisions of her church bulletins in an hour or less, it's a bad product.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.