3 ms·

I think submodules are a bit of a failed experiment, yes. Or, perhaps, a work in progress. Their usability is just awful. That said, if you don't use them the r

I think submodules are a bit of a failed experiment, yes. Or, perhaps, a work in progress. Their usability is just awful. That said, if you don't use them the rest of git works just fine. ;) Does Mercurial support submodules or the equivalent? Not in core, from what I can tell, although a casual search of Google reveals the third-party "Forest Extension": http://www.selenic.com/mercurial/wiki/index.cgi/ForestExtension http://www.selenic.com/mercurial/wiki/index.cgi/ForestExtens... There's some talk on a wiki about putting this extension's functionality into Mercurial proper, but the wiki link is broken. That doesn't bode well. I don't know Mercurial so I have no idea if Forest is actually being used by folks, if it's akin to git submodules or more akin to Braid, if it's got usability traps of its own, etc. The docs page is filled with TODOs.

mronge 18y ago
We use Forests and they are pretty awful. I would recommend against using that extension. It is awkward to work with, makes it hard to rollback your repos to a consistent state, and is painful when you have a change that applies to both repos.
- mechanical_fish 18y ago
  Aha, perhaps I have found the Mercurial equivalent of git submodules! ;) Although, actually, I'm pretty sure you can get git projects with submodules to roll back to consistent states. But it might take ten separate commands, five attempts, and a visit to the FAQ. Submodules are conceptually tricky and their workflow is a mess.
  - mronge 18y ago
    Sound exactly like forests. You CAN get back to a consistent state. But you have to be very careful look at the commit history and hg update a few times.
- undees 18y ago
  I've used forests on a few projects. On the upside, the commands don't cause unpleasant surprises; it's easy to guess what they'll do. But there are still far too many extra steps to do simple things like clone a remote forest and get all the sub-projects up to date. They need an "hg jfdi" command.
davidw 18y ago
svn's externals work quite well, on the other hand. I know, I know, svn is so 2007, but after fiddling around a bit with git, my impression is that spending time writing code is an order (if not more) of magnitude more important thank screwing around with a version control system, and svn mostly 'just works'. I think that eventually things like git and hg will surpass it, but version control isn't where your startup is going to "make or break" it (unless you're github:-).
- mechanical_fish 18y ago
  Well, I know nothing of SVN externals. But I tend to believe this guy who says that SVN externals are inferior to Piston, and that Piston is the equivalent of git's Braid: http://codeintensity.blogspot.com/2008/03/svn-externals-are-evil-use-piston-or.html http://codeintensity.blogspot.com/2008/03/svn-externals-are-... He strikes me as someone who has come by this lesson through direct, painful personal experience. I've settled on Braid for the moment, and we'll see how that goes. Submodules offer more features, but at the expense of my ability to explain them to anybody else.
- rcoder 18y ago
  I've settled into a pretty happy workflow using Git as a local snapshot of an upstream Subversion repository using git-svn. With a bit of discipline, you can keep things nicely in sync, and get the benefits of cheap-as-hell branching and local/offline commits without forcing your entire project team to migrate to a new VCS. I've got some notes on the subject on my blog: http://rcoder.net/content/daily-git-svn http://rcoder.net/content/daily-git-svn
- SwellJoe 18y ago
  svn's externals work quite well I found them quite painful. Links to external paths don't work, committing with multiple externals when one or more of the external repos are down has some sort of problem (though it's been a while and may have been fixed), doing anything from the external to the parent (like moving files) had some sort of problem as well (again, maybe fixed). It was enough of a problem that the project I was working on ended up with two repositories for the same code...and they would manually merge them periodically. Obviously sub-optimal and a big waste of time, but it was less trouble than the alternative of having every developer understand why the external repo had to be treated completely differently from the rest of the repository in many regards.
durin42 18y ago
Forests are out of date, but IIRC mpm is planning on personally tackling submodule support for release some time this summer (whenever the 1.3 release schedule is, I don't remember offhand).

mronge 18y ago

We use Forests and they are pretty awful. I would recommend against using that extension. It is awkward to work with, makes it hard to rollback your repos to a consistent state, and is painful when you have a change that applies to both repos.

mechanical_fish 18y ago
Aha, perhaps I have found the Mercurial equivalent of git submodules! ;) Although, actually, I'm pretty sure you can get git projects with submodules to roll back to consistent states. But it might take ten separate commands, five attempts, and a visit to the FAQ. Submodules are conceptually tricky and their workflow is a mess.
- mronge 18y ago
  Sound exactly like forests. You CAN get back to a consistent state. But you have to be very careful look at the commit history and hg update a few times.
undees 18y ago
I've used forests on a few projects. On the upside, the commands don't cause unpleasant surprises; it's easy to guess what they'll do. But there are still far too many extra steps to do simple things like clone a remote forest and get all the sub-projects up to date. They need an "hg jfdi" command.

davidw 18y ago

svn's externals work quite well, on the other hand. I know, I know, svn is so 2007, but after fiddling around a bit with git, my impression is that spending time writing code is an order (if not more) of magnitude more important thank screwing around with a version control system, and svn mostly 'just works'. I think that eventually things like git and hg will surpass it, but version control isn't where your startup is going to "make or break" it (unless you're github:-).

mechanical_fish 18y ago
Well, I know nothing of SVN externals. But I tend to believe this guy who says that SVN externals are inferior to Piston, and that Piston is the equivalent of git's Braid: http://codeintensity.blogspot.com/2008/03/svn-externals-are-evil-use-piston-or.html http://codeintensity.blogspot.com/2008/03/svn-externals-are-... He strikes me as someone who has come by this lesson through direct, painful personal experience. I've settled on Braid for the moment, and we'll see how that goes. Submodules offer more features, but at the expense of my ability to explain them to anybody else.
rcoder 18y ago
I've settled into a pretty happy workflow using Git as a local snapshot of an upstream Subversion repository using git-svn. With a bit of discipline, you can keep things nicely in sync, and get the benefits of cheap-as-hell branching and local/offline commits without forcing your entire project team to migrate to a new VCS. I've got some notes on the subject on my blog: http://rcoder.net/content/daily-git-svn http://rcoder.net/content/daily-git-svn
SwellJoe 18y ago
svn's externals work quite well I found them quite painful. Links to external paths don't work, committing with multiple externals when one or more of the external repos are down has some sort of problem (though it's been a while and may have been fixed), doing anything from the external to the parent (like moving files) had some sort of problem as well (again, maybe fixed). It was enough of a problem that the project I was working on ended up with two repositories for the same code...and they would manually merge them periodically. Obviously sub-optimal and a big waste of time, but it was less trouble than the alternative of having every developer understand why the external repo had to be treated completely differently from the rest of the repository in many regards.

durin42 18y ago

Forests are out of date, but IIRC mpm is planning on personally tackling submodule support for release some time this summer (whenever the 1.3 release schedule is, I don't remember offhand).