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:
just my 2 cents.
On Mon, Feb 14, 2011 at 2:18 AM, Siebrand Mazeland <s.mazeland(a)xs4all.nl> wrote:
Op 14-02-11 05:01 schreef Daniel Friesen <lists(a)nadir-seen-fire.com>om>:
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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
<a href="http://about.me/diederik">Check out my about.me
profile!</a>