On Mon, Feb 14, 2011 at 2:18 AM, Siebrand Mazeland s.mazeland@xs4all.nl wrote:
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)?
What's the problem with doing a hundred or more commits to different repositories? It be be trivial to script, if that's the problem.
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.
I don't see that fragmentation in a filesystem sense is relevant here. What disorganisation/disharmony are you talking about?
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.
The "decentralized" aspect will be in terms of who gets to change the code, not where it's put. In other words, I'd like to see anyone have equal standing to submit code, not have a separate "commit access" group. The code will still all be hosted by Wikimedia and made available centrally. A DVCS just makes it much easier to do development without having official approval by the upstream project.
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.
Checkouts are not just for developers. That's one of the pluses of a DVCS -- anyone can check out and maintain local patches in the version control, easily merging them with upstream changes. This is incredibly useful if you're maintaining local, site-specific hacks. I've done it with vBulletin for years (making my own git repository from their tarball releases). It also makes it very easy to submit your hacks for review upstream, if upstream is set up right.
On Mon, Feb 14, 2011 at 9:57 AM, Diederik van Liere dvanliere@gmail.com wrote:
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
I've used git a lot (I use it for everything I want to version) and Mercurial a fair bit (the W3C seems to like it), and I *strongly* prefer git. Major problems I have with Mercurial:
1) It doesn't support lots of useful functionality that's built into git unless you enable various extensions. This includes colored diffs, automatic paging for large output, and rebasing.
2) It makes it much too easy to delete stuff forever. I've had data loss once already due to getting confused by the merge UI during a rebase -- it kept no copies of my work. git always stores everything even after it's no longer accessible through normal means, like after a rebase or reset --hard. It only cleans up untouched stuff during periodic garbage collection.
On the other hand, there's basically nothing I've seen in Mercurial where I've said "wow, I wish git had that". So for what my opinion is worth, we should be going for git, not Mercurial, despite the former's quirks and flaws.