8 ms·

I use Mercurial, but have been exploring Git a little because of what you noted -- the community momentum seems to be headed that way.

by shutter 18y ago

thomasmallen 18y ago
Another vote for Mercurial. Whenever a project gets that "KoolAid" feel (Git, Rails, even Haskell at times) I tend to gravitate towards its competitors, so take that with a grain of salt, but I can say that Mercurial's been great for the small teams I've used it with. On larger projects, I've unfortunately only used Subversion, but I can say that it works, at least.
- gecko 18y ago
  I'll third the recommendation for Mercurial. There is no question that git has more community momentum--something which I hope will begin to change--but Mercurial is nevertheless an outstanding distributed version control system. Mercurial's default mode of operation has the benefit of being extremely Subversion-like--in a good way. Indeed, if you never interact with anyone else, most of the normal Subversion commands--ci, mv, rm, add, log--"just work." There is no git-style index to worry about, no rebasing, and the command set is small and regular. That means that the learning curve is far, far shallower than git. Yet it still provides the same distributed branching and merging as git, and, though it is slightly slower, the difference is truly negligible in my experience--maybe a couple percent difference at most. What about the incredible power of git, though? What if you actually want to be rebasing and rewriting your history all the time? When you want unfettered power in Mercurial, you've still got it. The `mq` extension, which can be enabled by adding a single line to your configuration file, allows you to do all the crazy patch rewriting, merging, splitting, and rebasing that git does.[1] But you can ignore that functionality if you want, and still have a very powerful and fast distributed change system. When Fog Creek looked at going to a distributed source control system last year, I advocated Mercurial over the competitors. Though the transition wasn't seamless, I've been extremely happy with the result. The Unix experience is extremely pleasant, and TortoiseHg (http://tortoisehg.sourceforge.net/ http://tortoisehg.sourceforge.net/) provides a surprisingly solid Windows experience out-of-the-box. If you can look past the fanboyism, I'd strongly encourage you to give Mercurial a try. I think it strikes a much better power-vs.-usability balance than git does. [1] Except microbranching. Mercurial doesn't currently support local named branches. You can achieve similar things by using mq with qguards, if you really need them, but in practice, I find it's usually easier to just clone a second repository. In practice, although I do miss microbranches sometimes, I've found I greatly prefer the streamlined workflow of Mercurial.
  - thomasmallen 18y ago
    Oh, right, I forgot. TortioseHg is a clincher if you want distributed VCS for Windows users. It makes things very easy.
  - cconstantine 18y ago
    The momentum here seems to be pretty heavily for Mercurial... maybe I should consider git to support the underdog ;) All kidding aside, Hg might be what we need. I'm looking into it now. Is it easy to import p4 history into Hg?
    - thomasmallen 18y ago
      Don't take our advice like that! Try it first: You may hate the way that one VCS works compared to another. Technical merits have less to do with this choice than your own preferences.
      - cconstantine 18y ago
        Hehe, yeah I'm trying to try it. Unfortunately it doesn't like any of the large files (anything over 10megs), and the windows shell plugin causes explorer to run like a dog. I've done some research on it and I want to like Hg. any advice on having it play nice with large files?
        silentbicycle 18y ago
        Maybe this is too far outside of the question, but particularly if you aren't going to be merging the large files, have you considered mirroring them with rsync (http://www.samba.org/rsync/ http://www.samba.org/rsync/) instead? I'm not sure tracking really large binary files is best handled by a VCS. I'm trying to read between the lines in your question, but would e.g. periodically making dated snapshots of the binaries and otherwise automatically mirroring around the newest version suffice? The Mercurial page on binary files (http://www.selenic.com/mercurial/wiki/index.cgi/BinaryFiles http://www.selenic.com/mercurial/wiki/index.cgi/BinaryFiles) doesn't say anything about especially large ones. Also, has anybody had good experience importing from p4 to hg on Windows? I've tried using tailor and some scripts from the mercurial wiki, but no success yet. One of these days I might write my own importer script (mostly because I need to import from five or six major branches, about 50k commits), but haven't had the time yet. (I'm working on Windows for similar reasons. Mercurial has been great for typical VC usage.)
- astrec 18y ago
  I tend to gravitate towards its competitor Me too - which is one paths that led me to Bazaar. Like your experience with Mercurial, Bazaar has done the trick on the smallish (<10) teams I've used it with, and the bzr-svn plug-in means you can still go out to play with your SVN using friends...
- jaaron 18y ago
  It's not like Mercurial is all that unpopular. Sun has switched its open source projects to hg. Mozilla is using it as well. All the subversion committers I know prefer hg over git as well.
  - thomasmallen 18y ago
    True popularity is different from hype. After all, Perl has always been more popular than Ruby.
jmtulloss 18y ago
I'm a big mercurial fan. After using it, I hate using SVN.

I use Mercurial, but have been exploring Git a little because of what you noted -- the community momentum seems to be headed that way.

by shutter 18y ago

I use Mercurial, but have been exploring Git a little because of what you noted -- the community momentum seems to be headed that way.

thomasmallen 18y ago

Another vote for Mercurial. Whenever a project gets that "KoolAid" feel (Git, Rails, even Haskell at times) I tend to gravitate towards its competitors, so take that with a grain of salt, but I can say that Mercurial's been great for the small teams I've used it with. On larger projects, I've unfortunately only used Subversion, but I can say that it works, at least.

gecko 18y ago
I'll third the recommendation for Mercurial. There is no question that git has more community momentum--something which I hope will begin to change--but Mercurial is nevertheless an outstanding distributed version control system. Mercurial's default mode of operation has the benefit of being extremely Subversion-like--in a good way. Indeed, if you never interact with anyone else, most of the normal Subversion commands--ci, mv, rm, add, log--"just work." There is no git-style index to worry about, no rebasing, and the command set is small and regular. That means that the learning curve is far, far shallower than git. Yet it still provides the same distributed branching and merging as git, and, though it is slightly slower, the difference is truly negligible in my experience--maybe a couple percent difference at most. What about the incredible power of git, though? What if you actually want to be rebasing and rewriting your history all the time? When you want unfettered power in Mercurial, you've still got it. The `mq` extension, which can be enabled by adding a single line to your configuration file, allows you to do all the crazy patch rewriting, merging, splitting, and rebasing that git does.[1] But you can ignore that functionality if you want, and still have a very powerful and fast distributed change system. When Fog Creek looked at going to a distributed source control system last year, I advocated Mercurial over the competitors. Though the transition wasn't seamless, I've been extremely happy with the result. The Unix experience is extremely pleasant, and TortoiseHg (http://tortoisehg.sourceforge.net/ http://tortoisehg.sourceforge.net/) provides a surprisingly solid Windows experience out-of-the-box. If you can look past the fanboyism, I'd strongly encourage you to give Mercurial a try. I think it strikes a much better power-vs.-usability balance than git does. [1] Except microbranching. Mercurial doesn't currently support local named branches. You can achieve similar things by using mq with qguards, if you really need them, but in practice, I find it's usually easier to just clone a second repository. In practice, although I do miss microbranches sometimes, I've found I greatly prefer the streamlined workflow of Mercurial.
- thomasmallen 18y ago
  Oh, right, I forgot. TortioseHg is a clincher if you want distributed VCS for Windows users. It makes things very easy.
- cconstantine 18y ago
  The momentum here seems to be pretty heavily for Mercurial... maybe I should consider git to support the underdog ;) All kidding aside, Hg might be what we need. I'm looking into it now. Is it easy to import p4 history into Hg?
  - thomasmallen 18y ago
    Don't take our advice like that! Try it first: You may hate the way that one VCS works compared to another. Technical merits have less to do with this choice than your own preferences.
    - cconstantine 18y ago
      Hehe, yeah I'm trying to try it. Unfortunately it doesn't like any of the large files (anything over 10megs), and the windows shell plugin causes explorer to run like a dog. I've done some research on it and I want to like Hg. any advice on having it play nice with large files?
      - silentbicycle 18y ago
        Maybe this is too far outside of the question, but particularly if you aren't going to be merging the large files, have you considered mirroring them with rsync (http://www.samba.org/rsync/ http://www.samba.org/rsync/) instead? I'm not sure tracking really large binary files is best handled by a VCS. I'm trying to read between the lines in your question, but would e.g. periodically making dated snapshots of the binaries and otherwise automatically mirroring around the newest version suffice? The Mercurial page on binary files (http://www.selenic.com/mercurial/wiki/index.cgi/BinaryFiles http://www.selenic.com/mercurial/wiki/index.cgi/BinaryFiles) doesn't say anything about especially large ones. Also, has anybody had good experience importing from p4 to hg on Windows? I've tried using tailor and some scripts from the mercurial wiki, but no success yet. One of these days I might write my own importer script (mostly because I need to import from five or six major branches, about 50k commits), but haven't had the time yet. (I'm working on Windows for similar reasons. Mercurial has been great for typical VC usage.)
astrec 18y ago
I tend to gravitate towards its competitor Me too - which is one paths that led me to Bazaar. Like your experience with Mercurial, Bazaar has done the trick on the smallish (<10) teams I've used it with, and the bzr-svn plug-in means you can still go out to play with your SVN using friends...
jaaron 18y ago
It's not like Mercurial is all that unpopular. Sun has switched its open source projects to hg. Mozilla is using it as well. All the subversion committers I know prefer hg over git as well.
- thomasmallen 18y ago
  True popularity is different from hype. After all, Perl has always been more popular than Ruby.

jmtulloss 18y ago

I'm a big mercurial fan. After using it, I hate using SVN.