Converting to Git?

classic Classic list List threaded Threaded
79 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Converting to Git?

Ævar Arnfjörð Bjarmason
On Sun, Mar 20, 2011 at 14:21, Ævar Arnfjörð Bjarmason <[hidden email]> wrote:
> On Wed, Mar 16, 2011 at 19:26, Yuvi Panda <[hidden email]> wrote:
>> I noticed that there's a github mirror of the svn repository at
>> https://github.com/mediawiki, but it is rather out of date. Any idea
>> if/when it could be made up-to-date again?
>
> I've been busy / out of town so I haven't fixed the MediaWiki mirror
> in GitHub yet.
>
> I'll do so soon.

I'm now re-running git-svn clone on the relevant paths (lost the
original), once that's complete I can update the mirror again.

I'm cloning from svn+ssh:// this time instead of my pushmi mirror
file://, so people cloning this should be able to push upstream with
git-svn without using git-filter-branch to rewrite the history first.

But actually the reason I did this mirror was as a proof of concept
for a (still incomplete) conversion to Git.

Is there still interest in that? I don't have a lot of time for it,
but I could help with that if people want to go that way.

I don't care much myself since I don't do MediaWiki development
anymore, but I'd be happy to help with it.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Converting to Git?

Yuvi Panda
On Sun, Mar 20, 2011 at 9:25 PM, Ævar Arnfjörð Bjarmason
<[hidden email]> wrote:
> But actually the reason I did this mirror was as a proof of concept
> for a (still incomplete) conversion to Git.
>
> Is there still interest in that? I don't have a lot of time for it,
> but I could help with that if people want to go that way.

If lack of people dedicated to this is why a migration isn't being
considered (I guess not), I volunteer myself.


--
Yuvi Panda T
http://yuvi.in/blog

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Converting to Git?

Neil Kandalgaonkar
I was waiting for RobLa to jump in here... as far as I know we are still
trying to find ways to move to Git, Some time after the dust settles on
1.17.

Rob?


On 3/22/11 12:27 AM, Yuvi Panda wrote:

> On Sun, Mar 20, 2011 at 9:25 PM, Ævar Arnfjörð Bjarmason
> <[hidden email]>  wrote:
>> But actually the reason I did this mirror was as a proof of concept
>> for a (still incomplete) conversion to Git.
>>
>> Is there still interest in that? I don't have a lot of time for it,
>> but I could help with that if people want to go that way.
>
> If lack of people dedicated to this is why a migration isn't being
> considered (I guess not), I volunteer myself.
>
>

--
Neil Kandalgaonkar (|  <[hidden email]>

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Converting to Git?

Ævar Arnfjörð Bjarmason
In reply to this post by Yuvi Panda
On Tue, Mar 22, 2011 at 08:27, Yuvi Panda <[hidden email]> wrote:

> On Sun, Mar 20, 2011 at 9:25 PM, Ævar Arnfjörð Bjarmason
> <[hidden email]> wrote:
>> But actually the reason I did this mirror was as a proof of concept
>> for a (still incomplete) conversion to Git.
>>
>> Is there still interest in that? I don't have a lot of time for it,
>> but I could help with that if people want to go that way.
>
> If lack of people dedicated to this is why a migration isn't being
> considered (I guess not), I volunteer myself.

Lack of time and people is indeed a factor. The import we have now
isn't a proper Git conversion.

I still have some vague notes here detailing approximately what we
need, some of these are out of date. The "Split up and convert"
section is somewhat accurate though:

    http://www.mediawiki.org/wiki/Git_conversion

No SVN to Git tool does exactly what we need due to our messy
history. I came to the conclusion that it was probably easiest to
filter the SVN dump (to e.g. fix up branch paths) before feeding the
history to one of these tools.

Of course even if we come up with a perfect conversion it's pretty
much useless if Wikimedia doesn't want to use it for its main
repositories. So getting a yes/no on whether this is wanted by WM
before you proceed with something would prevent you/others from
wasting their time on this.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Converting to Git?

Siebrand Mazeland
From what I understand, common thought is that phase3 and all individual
extensions, as well as directories in trunk/ aside from extensions and
phase3 will be their own repos. Possibly there will be meta collections
that allow cloning things in one go, but that does not allow committing to
multiple repos in one go without requiring scripting. This is a use case
that is used *a lot* by L10n committers and others. I think this is bad.

I am raising my objections against GIT as a replacement VCS for
MediaWiki's svn.wikimedia.org and the way people are talking about
implementing it again from an i18n perspective, and also from a
community/product stability perspective.

I raised this in the thread "Migrating to GIT (extensions)"[1,2] mid
February. My concerns have not been taken away. i18n/L10n maintenance will
be a lot harder and more distributed. In my opinion the MediaWiki
development community is not harmed by the continued use of Subversion. In
fact, the global maintenance - I define this as fixing backward
incompatibilities introduced in core in the 400+ extensions in Subversion,
as well as updating extensions to current coding standard - that many
active developers are involved in now, will likely decrease IMO, because
having to commit to multiple repos will make it more cumbersome to perform
these activities. Things that require extra work by a developer without
any obvious benefits out are just discontinued in my experience. As a
consequence, the number of unmaintained and crappy extensions will
increase, which is bad for the product image and in the end for the
community - not caring about that single extension repo is too easy, and
many [devs] not caring about hundreds [of extensions] is even worse.

Please convince me that things will not be as hard as I describe above, or
will most definitely not turn out as I fear. I am open to improvements,
but moving to GIT without addressing these concerns for the sake of having
this great DVCS is not justified IMO.

Siebrand


M: +31 6 50 69 1239
Skype: siebrand

[1]
http://lists.wikimedia.org/pipermail/wikitech-l/2011-February/thread.html#5
1812

[2]
http://lists.wikimedia.org/pipermail/wikitech-l/2011-February/051817.html


On 22-03-11 10:15 Ævar Arnfjörð Bjarmason <[hidden email]> wrote:

>On Tue, Mar 22, 2011 at 08:27, Yuvi Panda <[hidden email]> wrote:
>> On Sun, Mar 20, 2011 at 9:25 PM, Ævar Arnfjörð Bjarmason
>> <[hidden email]> wrote:
>>> But actually the reason I did this mirror was as a proof of concept
>>> for a (still incomplete) conversion to Git.
>>>
>>> Is there still interest in that? I don't have a lot of time for it,
>>> but I could help with that if people want to go that way.
>>
>> If lack of people dedicated to this is why a migration isn't being
>> considered (I guess not), I volunteer myself.
>
>Lack of time and people is indeed a factor. The import we have now
>isn't a proper Git conversion.
>
>I still have some vague notes here detailing approximately what we
>need, some of these are out of date. The "Split up and convert"
>section is somewhat accurate though:
>
>    http://www.mediawiki.org/wiki/Git_conversion
>
>No SVN to Git tool does exactly what we need due to our messy
>history. I came to the conclusion that it was probably easiest to
>filter the SVN dump (to e.g. fix up branch paths) before feeding the
>history to one of these tools.
>
>Of course even if we come up with a perfect conversion it's pretty
>much useless if Wikimedia doesn't want to use it for its main
>repositories. So getting a yes/no on whether this is wanted by WM
>before you proceed with something would prevent you/others from
>wasting their time on this.



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Converting to Git?

Chad
On Tue, Mar 22, 2011 at 10:25 AM, Siebrand Mazeland
<[hidden email]> wrote:
> Please convince me that things will not be as hard as I describe above, or
> will most definitely not turn out as I fear. I am open to improvements,
> but moving to GIT without addressing these concerns for the sake of having
> this great DVCS is not justified IMO.
>

I've actually come to partially agree with you since the last time we
discussed this. Really, the extension repository *should* remain in
Subversion as it is. I would, however, like to move phase3 to git.
Then i18n can just be two commits, instead of 400+

-Chad

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Converting to Git?

Roan Kattouw-2
2011/3/22 Chad <[hidden email]>:
> I've actually come to partially agree with you since the last time we
> discussed this. Really, the extension repository *should* remain in
> Subversion as it is. I would, however, like to move phase3 to git.
> Then i18n can just be two commits, instead of 400+
>
Extensions in SVN but phase3 in git? That doesn't really make sense to
me, TBH. Would it really be the end of the world if we had phase3 in
one repo and all extensions in another repo?

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Converting to Git?

Chad
On Tue, Mar 22, 2011 at 10:44 AM, Roan Kattouw <[hidden email]> wrote:

> 2011/3/22 Chad <[hidden email]>:
>> I've actually come to partially agree with you since the last time we
>> discussed this. Really, the extension repository *should* remain in
>> Subversion as it is. I would, however, like to move phase3 to git.
>> Then i18n can just be two commits, instead of 400+
>>
> Extensions in SVN but phase3 in git? That doesn't really make sense to
> me, TBH. Would it really be the end of the world if we had phase3 in
> one repo and all extensions in another repo?
>

Perhaps in the long run. I think in the short-run it'd be more pain-free
and perhaps a useful experiment to just move phase3 to git. Then we
can see how we feel about moving the rest over (or if we hate it and
want to go back)

-Chad

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Converting to Git?

Roan Kattouw-2
2011/3/22 Chad <[hidden email]>:
> Perhaps in the long run. I think in the short-run it'd be more pain-free
> and perhaps a useful experiment to just move phase3 to git. Then we
> can see how we feel about moving the rest over (or if we hate it and
> want to go back)
>
Hmm, that's a good point, let's not bite off too much the first time.

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Converting to Git?

Trevor Parscal-2
In reply to this post by Siebrand Mazeland
Your objections seem to be based on the assumption that you would need to have push access to all repositories, but I think that's the point of DCVS, you can just fork them, and then people can pull your changes in themselves (or using a tool). Pull requests could even be generated when things are out of sync.

I think it's quite possible this could make i18n/L10n work easier, not more difficult.

- Trevor

On Mar 22, 2011, at 7:25 AM, Siebrand Mazeland wrote:

> From what I understand, common thought is that phase3 and all individual
> extensions, as well as directories in trunk/ aside from extensions and
> phase3 will be their own repos. Possibly there will be meta collections
> that allow cloning things in one go, but that does not allow committing to
> multiple repos in one go without requiring scripting. This is a use case
> that is used *a lot* by L10n committers and others. I think this is bad.
>
> I am raising my objections against GIT as a replacement VCS for
> MediaWiki's svn.wikimedia.org and the way people are talking about
> implementing it again from an i18n perspective, and also from a
> community/product stability perspective.
>
> I raised this in the thread "Migrating to GIT (extensions)"[1,2] mid
> February. My concerns have not been taken away. i18n/L10n maintenance will
> be a lot harder and more distributed. In my opinion the MediaWiki
> development community is not harmed by the continued use of Subversion. In
> fact, the global maintenance - I define this as fixing backward
> incompatibilities introduced in core in the 400+ extensions in Subversion,
> as well as updating extensions to current coding standard - that many
> active developers are involved in now, will likely decrease IMO, because
> having to commit to multiple repos will make it more cumbersome to perform
> these activities. Things that require extra work by a developer without
> any obvious benefits out are just discontinued in my experience. As a
> consequence, the number of unmaintained and crappy extensions will
> increase, which is bad for the product image and in the end for the
> community - not caring about that single extension repo is too easy, and
> many [devs] not caring about hundreds [of extensions] is even worse.
>
> Please convince me that things will not be as hard as I describe above, or
> will most definitely not turn out as I fear. I am open to improvements,
> but moving to GIT without addressing these concerns for the sake of having
> this great DVCS is not justified IMO.
>
> Siebrand
>
>
> M: +31 6 50 69 1239
> Skype: siebrand
>
> [1]
> http://lists.wikimedia.org/pipermail/wikitech-l/2011-February/thread.html#5
> 1812
>
> [2]
> http://lists.wikimedia.org/pipermail/wikitech-l/2011-February/051817.html
>
>
> On 22-03-11 10:15 Ævar Arnfjörð Bjarmason <[hidden email]> wrote:
>
>> On Tue, Mar 22, 2011 at 08:27, Yuvi Panda <[hidden email]> wrote:
>>> On Sun, Mar 20, 2011 at 9:25 PM, Ævar Arnfjörð Bjarmason
>>> <[hidden email]> wrote:
>>>> But actually the reason I did this mirror was as a proof of concept
>>>> for a (still incomplete) conversion to Git.
>>>>
>>>> Is there still interest in that? I don't have a lot of time for it,
>>>> but I could help with that if people want to go that way.
>>>
>>> If lack of people dedicated to this is why a migration isn't being
>>> considered (I guess not), I volunteer myself.
>>
>> Lack of time and people is indeed a factor. The import we have now
>> isn't a proper Git conversion.
>>
>> I still have some vague notes here detailing approximately what we
>> need, some of these are out of date. The "Split up and convert"
>> section is somewhat accurate though:
>>
>>   http://www.mediawiki.org/wiki/Git_conversion
>>
>> No SVN to Git tool does exactly what we need due to our messy
>> history. I came to the conclusion that it was probably easiest to
>> filter the SVN dump (to e.g. fix up branch paths) before feeding the
>> history to one of these tools.
>>
>> Of course even if we come up with a perfect conversion it's pretty
>> much useless if Wikimedia doesn't want to use it for its main
>> repositories. So getting a yes/no on whether this is wanted by WM
>> before you proceed with something would prevent you/others from
>> wasting their time on this.
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Converting to Git?

Chad
On Tue, Mar 22, 2011 at 11:08 AM, Trevor Parscal <[hidden email]> wrote:
> Your objections seem to be based on the assumption that you would need to have push access to all repositories, but I think that's the point of DCVS, you can just fork them, and then people can pull your changes in themselves (or using a tool).
>

So now the Translatewiki guys will need to maintain a fork just for
i18n updates,
then have to wait for them to be pulled into main? That sounds like more work on
both Translatewiki as well as the developer--daily pull requests for
i18n updates,
seriously?

-Chad

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Converting to Git?

Ævar Arnfjörð Bjarmason
In reply to this post by Siebrand Mazeland
On Tue, Mar 22, 2011 at 15:25, Siebrand Mazeland <[hidden email]> wrote:

> Please convince me that things will not be as hard as I describe above, or
> will most definitely not turn out as I fear. I am open to improvements,
> but moving to GIT without addressing these concerns for the sake of having
> this great DVCS is not justified IMO.

I think the last time this came up I asked you why the difficulty of
what you have to do is a function of the number of repositories you
have to push to.

That shouldn't be the case, that's trivially scriptable. You'd still
be reviewing the same *content*. You'd just push to more locations.

So it's easy to get this right for you in Git, and you're the only
person AFAIC with this use case.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Converting to Git?

Max Semenik
In reply to this post by Trevor Parscal-2
On 22.03.2011, 18:08 Trevor wrote:

> Your objections seem to be based on the assumption that you would
> need to have push access to all repositories, but I think that's the
> point of DCVS, you can just fork them, and then people can pull your
> changes in themselves (or using a tool). Pull requests could even be
> generated when things are out of sync.

> I think it's quite possible this could make i18n/L10n work easier, not more difficult.

You seem to miss Siebrand's point: curerently, all localisation
updates take one commit per day. Splitting stuff to separate repos
will result in up to 400 commits per day that will also need to be pushed
and reintegrated - an epic waste of time and common sense. Or
localisation will simply lie aside in forks and people will miss them
when checking out from the "official" source.

--
Best regards,
  Max Semenik ([[User:MaxSem]])


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Converting to Git?

Trevor Parscal-2
My suggestion is that all of this "busy" work is highly automatable, but I'm sure he has a greater ability to assess the complexities of this work than I do.

In general I feel that we should be thinking about "how would we make this work" instead of "why should we not do this".

- Trevor

On Mar 22, 2011, at 8:33 AM, Max Semenik wrote:

> On 22.03.2011, 18:08 Trevor wrote:
>
>> Your objections seem to be based on the assumption that you would
>> need to have push access to all repositories, but I think that's the
>> point of DCVS, you can just fork them, and then people can pull your
>> changes in themselves (or using a tool). Pull requests could even be
>> generated when things are out of sync.
>
>> I think it's quite possible this could make i18n/L10n work easier, not more difficult.
>
> You seem to miss Siebrand's point: curerently, all localisation
> updates take one commit per day. Splitting stuff to separate repos
> will result in up to 400 commits per day that will also need to be pushed
> and reintegrated - an epic waste of time and common sense. Or
> localisation will simply lie aside in forks and people will miss them
> when checking out from the "official" source.
>
> --
> Best regards,
>  Max Semenik ([[User:MaxSem]])
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Converting to Git?

Ævar Arnfjörð Bjarmason
In reply to this post by Max Semenik
On Tue, Mar 22, 2011 at 16:33, Max Semenik <[hidden email]> wrote:

> On 22.03.2011, 18:08 Trevor wrote:
>
>> Your objections seem to be based on the assumption that you would
>> need to have push access to all repositories, but I think that's the
>> point of DCVS, you can just fork them, and then people can pull your
>> changes in themselves (or using a tool). Pull requests could even be
>> generated when things are out of sync.
>
>> I think it's quite possible this could make i18n/L10n work easier, not more difficult.
>
> You seem to miss Siebrand's point: curerently, all localisation
> updates take one commit per day. Splitting stuff to separate repos
> will result in up to 400 commits per day that will also need to be pushed
> and reintegrated - an epic waste of time and common sense. Or
> localisation will simply lie aside in forks and people will miss them
> when checking out from the "official" source.

I think you're missing the point that there's no reason why 400
commits should be harder than 1 in this case.

When he makes a commit now he ends up stat()-ing 400 files, but he
doesn't notice because it's all abstracted away.

Similarly he could make 400 commits by issuing one command, just like
he does today.

And what does "pushed and reintegrated" mean? He'd presumably push to
the canonical upstream, just like he does now.

(Or he could push somewhere else if people would like that, pulling
from that should also be trivial).

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Converting to Git?

K. Peachey
On Wed, Mar 23, 2011 at 2:00 AM, Ævar Arnfjörð Bjarmason
<[hidden email]> wrote:
> I think you're missing the point that there's no reason why 400
> commits should be harder than 1 in this case.
Code review comes to mind there.
-Peachey

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Converting to Git?

Siebrand Mazeland
In reply to this post by Trevor Parscal-2
On 22-03-11 16:38 Trevor Parscal <[hidden email]> wrote:


>My suggestion is that all of this "busy" work is highly automatable, but
>I'm sure he has a greater ability to assess the complexities of this work
>than I do.
>
>In general I feel that we should be thinking about "how would we make
>this work" instead of "why should we not do this".

IMO that a bridge too far. My question is "Why should we make this
happen?", and more specifically, what do our various stakeholders (which
groups?) gain or lose in case MediaWiki development would shift from
Subversion to Git? Only if the gain in the analysis would be greater than
the loss, it makes sense to me look look further into a move to Git.

On 22-03-11 16:08 Trevor Parscal <[hidden email]> wrote:

>Your objections seem to be based on the assumption that you would need to
>have push access to all repositories, but I think that's the point of
>DCVS, you can just fork them, and then people can pull your changes in
>themselves (or using a tool). Pull requests could even be generated when
>things are out of sync.


Yes, sir, indeed. Getting the L10n updates (as well as the i18n updates)
into the code as soon as possible is of paramount importance to the
success MediaWiki has in its i18n and L10n efforts. Having to wait until
possibly active repo maintainers pull updates is unacceptable. This would
kill translator motivation, and take us back years.

Siebrand



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Converting to Git?

Gerard Meijssen-3
In reply to this post by Trevor Parscal-2
Hoi,
When you look at the situation with the Toolserver where everybody has its
own toy source area you have a situation where internationalisation and the
upgrading of functionality to a production level is not happening. If GIT is
so great, then solve an existing pain which is the inability to collaborate
on toolserver tools.

GIT is cool, it is the flavour of the month. It is an improvement when it
proves itself in what is in my opinion a manifest dysfunctional source
management environment. When the Toolserver sources are all in a GIT
repository and its localisation becomes manageable, you have the proof of
the pudding demonstrating problem solving ability. When internationalisation
and localisation are part of the solution you are convincing that we can
move to GIT.
Thanks,
     GerardM

On 22 March 2011 16:08, Trevor Parscal <[hidden email]> wrote:

> Your objections seem to be based on the assumption that you would need to
> have push access to all repositories, but I think that's the point of DCVS,
> you can just fork them, and then people can pull your changes in themselves
> (or using a tool). Pull requests could even be generated when things are out
> of sync.
>
> I think it's quite possible this could make i18n/L10n work easier, not more
> difficult.
>
> - Trevor
>
> On Mar 22, 2011, at 7:25 AM, Siebrand Mazeland wrote:
>
> > From what I understand, common thought is that phase3 and all individual
> > extensions, as well as directories in trunk/ aside from extensions and
> > phase3 will be their own repos. Possibly there will be meta collections
> > that allow cloning things in one go, but that does not allow committing
> to
> > multiple repos in one go without requiring scripting. This is a use case
> > that is used *a lot* by L10n committers and others. I think this is bad.
> >
> > I am raising my objections against GIT as a replacement VCS for
> > MediaWiki's svn.wikimedia.org and the way people are talking about
> > implementing it again from an i18n perspective, and also from a
> > community/product stability perspective.
> >
> > I raised this in the thread "Migrating to GIT (extensions)"[1,2] mid
> > February. My concerns have not been taken away. i18n/L10n maintenance
> will
> > be a lot harder and more distributed. In my opinion the MediaWiki
> > development community is not harmed by the continued use of Subversion.
> In
> > fact, the global maintenance - I define this as fixing backward
> > incompatibilities introduced in core in the 400+ extensions in
> Subversion,
> > as well as updating extensions to current coding standard - that many
> > active developers are involved in now, will likely decrease IMO, because
> > having to commit to multiple repos will make it more cumbersome to
> perform
> > these activities. Things that require extra work by a developer without
> > any obvious benefits out are just discontinued in my experience. As a
> > consequence, the number of unmaintained and crappy extensions will
> > increase, which is bad for the product image and in the end for the
> > community - not caring about that single extension repo is too easy, and
> > many [devs] not caring about hundreds [of extensions] is even worse.
> >
> > Please convince me that things will not be as hard as I describe above,
> or
> > will most definitely not turn out as I fear. I am open to improvements,
> > but moving to GIT without addressing these concerns for the sake of
> having
> > this great DVCS is not justified IMO.
> >
> > Siebrand
> >
> >
> > M: +31 6 50 69 1239
> > Skype: siebrand
> >
> > [1]
> >
> http://lists.wikimedia.org/pipermail/wikitech-l/2011-February/thread.html#5
> > 1812
> >
> > [2]
> >
> http://lists.wikimedia.org/pipermail/wikitech-l/2011-February/051817.html
> >
> >
> > On 22-03-11 10:15 Ævar Arnfjörð Bjarmason <[hidden email]> wrote:
> >
> >> On Tue, Mar 22, 2011 at 08:27, Yuvi Panda <[hidden email]> wrote:
> >>> On Sun, Mar 20, 2011 at 9:25 PM, Ævar Arnfjörð Bjarmason
> >>> <[hidden email]> wrote:
> >>>> But actually the reason I did this mirror was as a proof of concept
> >>>> for a (still incomplete) conversion to Git.
> >>>>
> >>>> Is there still interest in that? I don't have a lot of time for it,
> >>>> but I could help with that if people want to go that way.
> >>>
> >>> If lack of people dedicated to this is why a migration isn't being
> >>> considered (I guess not), I volunteer myself.
> >>
> >> Lack of time and people is indeed a factor. The import we have now
> >> isn't a proper Git conversion.
> >>
> >> I still have some vague notes here detailing approximately what we
> >> need, some of these are out of date. The "Split up and convert"
> >> section is somewhat accurate though:
> >>
> >>   http://www.mediawiki.org/wiki/Git_conversion
> >>
> >> No SVN to Git tool does exactly what we need due to our messy
> >> history. I came to the conclusion that it was probably easiest to
> >> filter the SVN dump (to e.g. fix up branch paths) before feeding the
> >> history to one of these tools.
> >>
> >> Of course even if we come up with a perfect conversion it's pretty
> >> much useless if Wikimedia doesn't want to use it for its main
> >> repositories. So getting a yes/no on whether this is wanted by WM
> >> before you proceed with something would prevent you/others from
> >> wasting their time on this.
> >
> >
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Converting to Git?

Ryan Lane-2
> When you look at the situation with the Toolserver where everybody has its
> own toy source area you have a situation where internationalisation and the
> upgrading of functionality to a production level is not happening. If GIT is
> so great, then solve an existing pain which is the inability to collaborate
> on toolserver tools.
>
> GIT is cool, it is the flavour of the month. It is an improvement when it
> proves itself in what is in my opinion a manifest dysfunctional source
> management environment. When the Toolserver sources are all in a GIT
> repository and its localisation becomes manageable, you have the proof of
> the pudding demonstrating problem solving ability. When internationalisation
> and localisation are part of the solution you are convincing that we can
> move to GIT.

Toolserver has a social problem, not a technological one. They have
the ability to use SVN, or a source control system of their choosing,
yet they don't. This thread is discussing a perceived problem with a
tool we are already successfully using. Let's focus on one issue at a
time.

- Ryan Lane

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Converting to Git?

Chad
In reply to this post by Siebrand Mazeland
On Tue, Mar 22, 2011 at 12:11 PM, Siebrand Mazeland
<[hidden email]> wrote:

> On 22-03-11 16:38 Trevor Parscal <[hidden email]> wrote:
>>My suggestion is that all of this "busy" work is highly automatable, but
>>I'm sure he has a greater ability to assess the complexities of this work
>>than I do.
>>
>>In general I feel that we should be thinking about "how would we make
>>this work" instead of "why should we not do this".
>
> IMO that a bridge too far. My question is "Why should we make this
> happen?", and more specifically, what do our various stakeholders (which
> groups?) gain or lose in case MediaWiki development would shift from
> Subversion to Git? Only if the gain in the analysis would be greater than
> the loss, it makes sense to me look look further into a move to Git.
>

I'd like to really underline this point here. I am *not* sold on using
Git, and I think it's premature to assume that we have to make Git
work. Siebrand has raised some valid concerns that I think bear
considering, even if the process is (semi)automated. Also, the
comment about code review is also a point. Right now, CodeReview
does not support Git, and really the implementation was never built
with Git in mind. I think we could hack it in, but it wouldn't be pretty
and if Git's the answer then I think we'll be leaving this tool in favor
of something else (I and many others like Gerrit quite a bit). I think
migrating our repository is a huge task--one I think should be done
slowly, with caution, and a very clear exit path if things go wrong.
The status quo isn't great, but we can live with it if Git doesn't pan
out how we'd like.

That all being said, I'd like to propose again that we only seek to
move phase3 at this time. It's a much smaller chunk of the rest
of the repo and is pretty self-contained. It'd give us a chance to
work with a smaller dataset both for the metadata rewriting as well
as getting *used* to the workflow. We've all used Git before, but
every organization's workflow is a little different. Once we spend
awhile doing that, I think we'll be in a much better position to evaluate
whether we'd like to move extensions over or not.

-Chad

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
1234