On Mon, Feb 14, 2011 at 2:18 AM, Siebrand Mazeland <s.mazeland(a)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(a)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.