If I am not mistaken then mercurial has better support for highly modularized open source software projects. You can use a mercurial subrepository (which is very similar to svn external and git submodule). According to their manual: "Subrepositories is a feature that allows you to treat a collection of repositories as a group. This will allow you to clone, commit to, push, and pull projects and their associated libraries as a group." see: http://mercurial.selenic.com/wiki/Subrepository http://mercurial.selenic.com/wiki/NestedRepositories
just my 2 cents. On Mon, Feb 14, 2011 at 2:18 AM, Siebrand Mazeland <s.mazel...@xs4all.nl> wrote: > > Op 14-02-11 05:01 schreef Daniel Friesen <li...@nadir-seen-fire.com>: > > >Ohh... if the translatewiki guys are looking for a dummy for > >streamlining support for extensions based in git in preparation for a > >git migration if we do so, I'd be happy to offer monaco-port up as a > >existing extension (well, skin) using git that could be used as a test > >for streamlining git support. ;) having monaco-port get proper i18n > >while it's still not up to a level I believe I want to commit it into > >svn yet wouldn't be a bad thing. > > With regards to i18n support it is not clear to me how translatewiki staff > would deal with 100+1 commits to different repo's every day if core and > extensions would each be in individual repos. Can you please explain how > Raymond would be working with Windows and Git in the proposed structure > updating L10n for 100 extensions and MediaWiki core? How would > translatewiki.net easily manage MediaWiki updates (diff review/commits)? > > I'm not particularly looking forward to having to jump through a huge > series of hoops just to keep checkouts for single extensions small. If > that is the real issue, extension distribution should get another look as > this might indicate that ExtensionDistributor does not work as expected. I > have currently checked out all of trunk, and for translatewiki.net we have > a selective checkout of i18n files for extensions and we have a checkout > for core and the installed extensions. The fragmentation and > disorganisation/disharmony that will exist after creating 450 GIT repos > instead of one Subversion repo as we currently have is also something I am > not looking forward to. > > Source code management is now centralised, and correct me if I'm wrong, > but we encourage developers to request commit access to improve visibility > of their work and grow the community. "Going distributed" in the proposed > way, would hamper that, if I'm correct. I think the relative lower > popularity of extensions that are maintained outside of svn.wikimedia.org > are proof of this. I am not in favour of using GIT in the proposed way. I > think core and extensions should remain in the same repo. Checkout are for > developers, and developers should get just all of it. > > Siebrand > > > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- <a href="http://about.me/diederik";>Check out my about.me profile!</a> _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
