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.mazeland@xs4all.nl wrote:
Op 14-02-11 05:01 schreef Daniel Friesen lists@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>