Fwiw I decided to take a more detailed look at the quoted article and there's a couple of things I noticed:
'Don’t blink…' The answer to this point is simple. The reason we'd like this is we don't expect people pulling in new versions of the subrepo regularly. We expect that to happen on a regular basis in an automated way, and only occasionally by developers. Mercurial subrepositories also solve the latter part of the problems mentioned here by making an hg up update both your parent and subrepository, preventing the 'accidental' reverts mentioned in the article. 'Merging? Ha!' Again, we don't expect to be 'merging' changes to the subrepository changeset we're linked to. In the sense that unless well coordinated (in which case you know what you're doing and it seems the concerns in the article would not really apply) you're not really merging very often here. You might have branches on the subrepository in some cases where you're fixing an aurora bug for example, but I don't foresee serious problems there. That's only really a small amount of extra work for a graphics developer that I think is perfectly acceptable. I'd say we've had a lot more trouble in the past merging libraries we manually pulled into our tree. 'Oh, were you using that?' Although I find this bit of concern is valid, I think it's a problem that really only occurs when there's a lot of interdependencies where you're editing both the parent and subrepo at once. It seems to be this problem would not occur if you landed changes to your subrepository always to the tip of that subrepository, and not push them directly from your parent repository. For example if you were working on a new feature, even if you were doing so while working with all of mozilla central, you'd update the subrepo, develop your new code, push that to the subrepository, but not necessarily push the updated tag to mozilla-central. This workflow is a little different, but I don't think it's problematic. Finally there's an interesting one: 'What am I supposed to do with this?' 'Push changes from the submodule and not the parent repository? No one knows to use your new submodule changes.' Well, this sounds a lot like just using submodules in a situation where there isn't really a distinct project that you're using the submodule for, when you push changes to a submodule it's not that 'noone knows to use it'. It means new features/bugfixes have become available in your dependency project. This is fine, they'll be picked up in time on an automated update, or when they're required earlier. 'Push changes from the parent repository and not the submodule? Congratulations, no one can use your new commits because they don’t have the right submodule commit available to check out.' Mercurial actually doesn't seem to allow this as far as I've been tell (i.e. your parent push will also ensure your subrepos are pushed). However it is again an indication that there's not actually a distinct development process going on here. The default process here should be to add a new feature, tests, etc. Push them to the subrepo, ensure all tests are passing everywhere and that everything is ready, and then start using it in the parent when it becomes available. In the rare cases of API changes which are incompatible, a little more care is required, but when making changes like that I'd say it's actually -good- to be aware of that, especially when we're in a situation where multiple projects (i.e. Gecko and Servo) use the API. And if you're consciously making such a change making sure you push your subrepo change first and then update your parent repository with the API changes and the tag update seems like a very easy thing. All in all having read, and thought for a while, about this particular post of concerns has not really made me feel like it's something we don't want to do. Although there seems to be some minor things which are a little better handled with mercurial subrepositories. I wonder if it would be possible to make sure git's improved in that area before we switch mozilla-central to it, if the experiment goes through and succeeds. Bas ----- Original Message ----- From: "George Wright" <geo...@mozilla.com> To: dev-platform@lists.mozilla.org Sent: Thursday, March 28, 2013 2:08:45 AM Subject: Re: Moz2D Repository Creation On 03/27/2013 07:37 PM, Robert O'Callahan wrote: > I predict that eventually we'll want to switch mozilla-central to git. (I'm > not in favour of it, but hg is not the DVCS of the future.) So, git users > not liking git's subrepositories gives me pause and I think it's imperative > to consider the situation of git users now and after a hypothetical > mozilla-central switch to git. I've investigated submodules before to try to solve this exact problem and came away pretty unimpressed. This was nearly 3 or 4 years ago, but I doubt things have changed much. A quick search suggests that other people are also similarly unimpressed with submodules, such as the post at http://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/ I suspect the answer here would be to choose a solution that is easily convertible to a repo-style setup. We already have experience in-house with repo due to Android and B2G and it seems to mostly do what we would be aiming for with this project. On the main note (which I already brought up on IRC): I would be very interested in seeing whether this experiment succeeds or not, as I'd like to get to the stage where the entire Skia source tree inside mozilla-central is just a checkout of upstream Skia, whether that's via submodules or repo or whatever. George _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
