http://www.perlmonks.org?node_id=961583

Hello fellow monks.

I come before you to ask what you think about distributed version control in a mature and flame-free way. How do you feel about git and mercurial? What do you think about Github and Bitbucket?

I guess I'll start. Personally, I use git for all my projects. I used to be a big subversion user, but I like git more, mostly because of its mainstream coverage and the direction it's headed. Not to be a bandwagon hopper, but it's the truth. I also am a fan of Github, although most of my projects prohibit its usage. This also likely plays into my usage of git, as I have used git and Github as a way to get my daily use software, libraries, Vim plugins, etc... That being said, I do like mercurial and Bitbucket. However, I think that's because they definitely look, act, and feel like shameless clones... I know that isn't the case, but Bitbucket does "borrow" alot of Githubs ideas. And so does mercurial

So, I'm just curious where other Perl users stand and how useful/uselss they find git, Github, mercurial, or Bitbucket.

  • Comment on Thoughts on Git, Mercurial, Github, and Bitbucket.

Replies are listed 'Best First'.
Re: Thoughts on Git, Mercurial, Github, and Bitbucket.
by moritz (Cardinal) on Mar 26, 2012 at 05:50 UTC

    Both git and mercurial (and darcs for that matter) are huge improvements over centralized SCMs like SVN. You could argue for days which one to use, and won't get any conclusive results.

    I happen to prefer git, and I know a lot of other Perl people do. It wasn't much of a conscious decision, i just contributed to a few projects that used git, and thus learned it and eventually liked it. Later I learned a bit of hg too, and also liked it, though not enough to switch.

    The perl 5 core is held in a git repo, as well as all serious Perl 6 compilers and nearly all of the Perl 6 modules.

    I also get the impression that many Perl 5 modules use git (and I know it from a few big ones, like DBIx::Class, Moose and Mojolicious), many more than Mercurial.

    As for the websites, it's been ages since I used bitbucket, and back then it didn't support any pull requests, so any opinion I could offer would probably be too out of date to take seriously.

      Both git and mercurial (and darcs for that matter) are huge improvements over centralized SCMs like SVN. You could argue for days which one to use, and won't get any conclusive results.
      This. git and Mercurial are pretty much equivalent.

      I wouldn't use Darcs, because it has (had?) huge performance problems with large repositories, and doesn't seem to have enough developers. There's also Bazaar, but it is terrible. (Emacs adopted it some time ago, and someone quickly created a git gateway.)

      Definitely agree with you. Both git and hg are improvements on older tools. Bitbucket does allow pulls now, but it is in Githubs shadow. It casts a huge.

      Has anyone taken a look at the help screens for git and hg? Dear Lord, looks shockingly similar. So similar... Draws a parallel from their respective 'social' websites on purpose? Feels like a version control conspiracy.

        No need for any conspiracy theories; copying cool features from other programs and websites is an accepted development strategy. After all, why should should you only implement your own good ideas?

Re: Thoughts on Git, Mercurial, Github, and Bitbucket.
by GrandFather (Saint) on Mar 26, 2012 at 09:26 UTC

    At work this year we switched from CVS to Mercurial after many years of talk (SVN was on the cards for a long time). One of our developers looked hard at Git, Mercurial, SVN, Bazaar and possibly other systems. At the end of the day for us the decision fell to Mercurial because it has good Mac and Windows GUI interfaces and by most other metrics there wasn't much that was important to us to pick between Mercurial and Git.

    I've been using Mercurial and Bitbucket for about a year now and am very happy with it. I have no experience whatsoever of Git. I have noticed frequent references to Git in the Mercurial documentation, mostly as a fairly emotionless comparison of features to ease porting concepts from one context to the other.

    The big difference is between distributed systems such as Git and Mercurial, and single repository (often server based) systems such as CVS and Subversion. Having worked with CVS, SVN and Mercurial I'm very happy the decision went the distributed repo way!

    True laziness is hard work

      Do you have centralized or distributed SW development? On my project we only have centralized development. I didn't see the advantage to move to a distributed approach and was happy to make to step from CVS to SVN (for us already a big step!). SVN works fine for us. We have many tools and Subversion is well supported in terms of plugins for integration (Jira, Hudson etc.) Could you think of reasons to use a distributed approach while having only centralized SW development? I could be wrong but it sounds like adding complexity for something I don't really need. I could be completely wrong though;)

      Cheers

      Harry

        Could you think of reasons to use a distributed approach while having only centralized SW development?

        I would hate to give up cheap and easy local branching. (I've used both Mercurial and git but prefer git. Either one allows this.)

        I don't think I understand the concept of "centralized development" except perhaps if there is a single developer. In our case we have 20 developers working on different aspects of maybe 10 different but related projects at any time out of a pool of around 40 projects, all of which share code. Using a distributed revision control system means that we can easily maintain central dev and stable versions of each repo. Developers use a local clone of the repos they are working on (we use Mercurial's sub-repo management facilities a lot!) and run it as a local sandbox repo, syncing from the central repos and workmates repos as they need.

        It sounds like anarchy, but works very well. It also works very well with our nightly builds which build all projects against the central repos. For dev builds the nightly build can be against the tip version of each of the sub-repos involved. We may have almost any number of our developers working on a specific project at a time and we may have several developers updating the same file in the context of different projects at the same time - mostly it just works.

        Doing this with a single central repo would be a nightmare! We were doing it with CVS and merges between branches were terrible with many manual checks and balances and much gnashing of teeth. SVN may have been a little better, but no where near as good as using a distributed system.

        If you have the chance try moving one of your projects from SVN to Mercurial or Git. Mercurial (at least, don't know about Git) can even use an existing SVN repo, but I'm not sure what the down side may be doing that.

        There is some pain moving from CVS and to a lesser extent from SVN in figuring out how to break up an existing repo. Mercurial at least doesn't allow you to cherry pick parts of a repo to generate a checkout that is a sub-set of the total repo. Using sub-repos fixes that to a large extent, but you are likely to end up moving stuff around between repos if you don't think hard about the structure up front.

        True laziness is hard work
Re: Thoughts on Git, Mercurial, Github, and Bitbucket.
by DrHyde (Prior) on Mar 26, 2012 at 10:05 UTC

    I use git (and github) both for my own stuff and also for work. I like it. It has plenty of wrinkles and irritating misfeatures, but then what software doesn't?

    We mostly use it as "CVS with offline commits", a job that it does really well. I'm not convinced that "distributed version control" is such a killer feature though, as at *some* point you still need to pull all your changes together to make a release. Working in separate cloned copies looks just like working in branches to me. But then I've not done much serious work on the sort of really big projects that are alleged to benefit from it, so what would I know.

      I'm not convinced that "distributed version control" is such a killer feature though, as at *some* point you still need to pull all your changes together to make a release.
      The keyword here being some point. Distributed means that people can still make commits, even if the central server is down, or if they're working on a train or a rocket.
      Working in separate cloned copies looks just like working in branches to me.
      Yeah, CVS is great at branching. Unfortunally, it's not so great at merging. It used to be that creating a branch was a milestone: you'd release version 1.1, and branched of 1.1.1.1 as a maintenance branch. With more modern version control systems, branching is what people do all the time, since merging is trivial.

        I was under the impression that people mean something more than just "offline commits" when they talk about how awesome a distributed VCS is.

        Comparing to cvs is perhaps not quite right. Maybe it's better to compare with subversion (which is "cvs with better branching"), where branching and merging is easy. Sure, svn merges still have their problems, but they are minor.

Re: Thoughts on Git, Mercurial, Github, and Bitbucket.
by Tux (Canon) on Mar 26, 2012 at 10:11 UTC

    Our choice to use git in our company project was only based on availability (or easy to make it available) on the platform it had to run on: HP-UX.

    When you are on Linux, just use your fav package manager to install all, compare and choose what fits best (yes, I've done so with most Version Control Systems on my Linux box to at least see what they offer). On HP-UX however, I didn't even consider Mercurial, because it is Python based, and I did not get Python installed on that box (I also must admit I didn't try very hard as we're more a perl company and don't need python for anything else). I gave up on svn after a week of trying: it has way to many dependencies that do not build on 64bit HP-UX and the response from their developers was alarmingly "I don't care" like. Git otoh built almost out of the box. I had it up and running in less than 5 hours. Took yet another day to get the GUI's working, but one doesn't really need it for a working VSC.

    Our projects were in SCCS which started to fail when files started to contain UTF-8, so there was a lot of pressure to move from SCCS to anything more modern that worked. Our first choice was to compare svn and git, but as svn didn't compile, we chose git and up to now never regret that.

    GUI-wise, I have never seen a more inituïtive interface than p4v, the GUI for perforce and I still think that git-gui and gitk differ too much in presentation style and user experience. It should have been one single front-end. As JavaFan said: it's software. Whatever you choose/use will suck somewhere. I personally hate svn because it is so extremely counter-intuitive and centralized (and slow compared to git), but if I have to, I'll use it (though I prefer to make git-svn clones if I can).


    Enjoy, Have FUN! H.Merijn

      Our projects were in SCCS which started to fail when files started to contain UTF-8

      WOW! Really ... in 20XX you were still on SCCS ... now that's some technical debt. Twenty years ago, I transitioned a project from SCCS to RCS since the build process was bogged down by SCCS 'apply patches to get current file' architecture (maybe it changed ... but I doubt it).

      -derby
Re: Thoughts on Git, Mercurial, Github, and Bitbucket.
by tobyink (Canon) on Mar 26, 2012 at 10:01 UTC

    I moved most of my code from self-hosted SVN to Mercurial repositories on bitbucket.org several months ago.

    I always found git completely horrible to use, but switching from svn to hg has been a relatively simple matter.

    Now that I've switched to hg, I feel I have a better understanding of git, as they're not a million miles apart, and I am reasonably comfortable working on other peoples' git projects. However, UX-wise I still think hg is streets ahead of git, and have no desire to switch away from hg.

    The main advantage of distributed SCM for me personally (and I realise there are far bigger advantages that may be applicable to other people - they just don't necessarily apply to me!) is the ability to check in source code changes without an Internet connection, as I often code on trains, etc.

    perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

      I’ve had a similar experience with these three.

      Originally a (mostly happy) SVN user, we didn’t branch unless really needed, and being a small bunch of coders usually not working on the same files back then, we didn’t conflict with each other. I’d heard of git (and a little later Mercurial), and in fact started storing my university stuff in a git repo on my computer(s), more or less successfully. I have lost some data with it, because it’s ridiculously easy to use git in a clumsy way. I ended up not liking its user interface due to the weird naming of commands and the relatively insane defaults — but I hear it has improved a lot since 2007.

      I ended up doing stuff in Hg instead, primarily because it felt so similar to SVN — if SVN is CVS Done Right, I’d say Mercurial is SVN Done Right (I’m sure this sets off alarms in git users’ heads :D). The user interface feels sane (albeit it’s not without slight pricks hidden here and there; but no software is perfect) and it’s very easy for people to switch to it without clobbering their work with a careless or misunderstood command. Back when I tried git, the documentation was rather… arcane. Or it felt like it anyway. Mercurial just works, and you can do advanced crazy stuff in it if you really want to (now with Phases, even rebasing is decent). I do also very much like the immutability of the history here — git users often seem to be obsessed with making the tree look more like a flagpole (after the fact) rather than a shunting yard :)

      Back to work, we’ve moved one of our projects over to Mercurial and have been very pleased with it so far. Started moving other projects to it too, the other users seem to grok hg as well now. This is pretty cool.

      And just as you said: I learned the way things work in a DVCS from Mercurial (way easier than I could from git) — and as a result I understand the way git works much better than I did with the SVN-only background.

      Recently got interested in getting down some git-fu simply because GitHub is awesome (and I don’t like Bitbucket that much), and because Perl stuff is primarily git-hosted. My second language is Python though, so… the hg-fu will come handy eventually when I can code in it again.

Re: Thoughts on Git, Mercurial, Github, and Bitbucket.
by JavaFan (Canon) on Mar 26, 2012 at 09:06 UTC
    $WORK uses git. Perl uses git. So, I have to know git. It's software, so, by definition it sucks. There hasn't been a reason for me to learn mercurial or svn, or whatever version control system is in vogue today. I'm sure they suck as well. Just as CVS, RCS, SCCS before them. And next years tool will suck as well.

    git does the job for me. And since I already have to know git, I use for personal projects as well. I'm sure mercurial and others would do the jobs as well. There just hasn't been any justification to learn something else.

Re: Thoughts on Git, Mercurial, Github, and Bitbucket.
by bms (Monk) on Mar 26, 2012 at 16:57 UTC
      So, I personally believe in the last link in the list. What do you guys think?

      ...and the OP exhibit some cognitive dissonance given the contents of the link, and its maturity level, in which you profess belief.

        Well, given the technical implications given and the fact that most *normal* people like a good chuckle, I stand by my assertion and believe a mature discussion can include humor.
Re: Thoughts on Git, Mercurial, Github, and Bitbucket.
by jdporter (Paladin) on Mar 26, 2012 at 15:29 UTC

    I don't have much to add to the conversation, but my one anecdote: A couple years ago I needed to find a vc system for "very large" files — 1 to 100 gigabytes in size. Binary files of arbitrary structure (e.g. Oracle dumps) such that management of diffs by delta was not feasible. The result of my market survey identified Mercurial based on the availability of plug-in modules for handling unusual vc needs such as this. (But for all I know, git has similar capabilities. If it did at that time, I wasn't able to find it easily.)

Re: Thoughts on Git, Mercurial, Github, and Bitbucket.
by dns (Initiate) on May 05, 2013 at 15:18 UTC
    First I learned SVN, after that I learned both Mercurial & Git. As regular Windows users I find Mercurial is much more easier to use than Git, and Git support is very awfull back then (circa 2010-2011). However I completely switch to Git this month, because the porting of Git on Windows (TortoiseGit) is much better in recent years. Once your know how to use Git, you will not look for any other alternatives ... IMHO
Re: Thoughts on Git, Mercurial, Github, and Bitbucket.
by Anonymous Monk on Mar 26, 2012 at 06:32 UTC

    in a mature and flame-free way

    $bms =~ s/m//

    :)