Switch to Git or Mercurial for share-extras

[Peter Löfgren]

May I propose that share-extras switch from Subversion to Git or Mercurial?

It may be just a preference of mine, but there is so much better
support for branching and distributed development. For example in the
Media Previews project I can branch out and start implementing the new
looks of pdf.js viewer without messing with stability of 'master'. Or
the support for server side clones, anyone can create their own clone,
and then contribute changes/updates without becoming a core member of
the project.

Cheers,
Peter Löfgren

[Erik Billerby]

+1 (prefer git)

:)

/Erik

> --
> You received this message because you are subscribed to the Google Groups "Share Extras Development" group.
> To post to this group, send email to share-ext...@googlegroups.com.
> To unsubscribe from this group, send email to share-extras-de...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/share-extras-devel?hl=en.
>

[Will Abson]

I agree we should move to Git. It just needs someone to coordinate it,
i.e. make sure that the code is moved over correctly (Google have a
guide for this), that all docs get updated and that anyone with a
checked out SVN copy (not just committers) knows that they need to
move over to the Git repo.

If we can sort out a better strategy for docs (as I suggested in my
other mail) then that will help us to make the updates there, then we
just need to implement a plan. Does that sound reasonable?

Cheers,
Will

[Will Abson]

Share Extras will be moving to a new platform in the next few weeks.
The new platform will be GitHub, with the version control obviously
provided by Git instead of Subversion, which is used at present.

There are many reasons for moving to Git from Subversion. I've spent a
while reviewing the project issue list this week and it's clear to me
that there are many enhancement requests which may not be appropriate
to make in the main Extras code base, or are simply not achievable
within the project due to people's time constraints.

Git will enable the wider community to fork individual any add-on as
they feel the need to. I hope this will lead to more contributions
back to the main project and foster greater collaboration (and perhaps
a bit of competition?) with others.

Specifically, there is also the need to improve on the localisation of
add-ons in a consistent manner, and there are some great tools
available for doing that based on Git.

Whilst I had originally intended to simply migrate to a new Git VCS
within Google Code, the frequent downtime and increasingly poor
feature set and user interface when compared to other providers has
led me to conclude that it is not a viable platform for future
development.

In contrast, GitHub supports the notion of projects within an overall
organisation much better (I have already registered Share Extras as an
organisation) and has some great options for improving our
documentation using cool standards such as Markdown.

I propose to migrate the current trunk codeline (and perhaps the 1.0
branch should time allow) at the end of August. There are several
things that committers need to do before then, in order to help make
it a success, such as ensuring that they have a README.md file in all
their projects (this will become the main source of documentation,
rather than the wiki), and helping to close down any issues that
remain open on Google Code (issues will not be migrated over).

As always, if you have any feedback, please let me know. Otherwise I
will be in touch with the main committers separately in the coming
week or so.

Cheers,
Will

[Peter Löfgren]

Hi,

Sorry for a late response.

How has your plans for Github progressed? I'm very much for this move to github.

I did a test following this guide https://help.github.com/articles/importing-from-subversion so we should be able to get all history along.

I do have some updates for Media Viewer, shall I commit them now to google code? I also made updates for 4.2, but that is much easier to handle with branching on github, so I do not know how to commit that now.

Cheers,

Peter

2012/7/20 Will Abson <will....@gmail.com>

[Will Abson]

Hi Peter,

I finally managed to get round to taking a look at the svn2git tool, and the docs certainly look good.

The only thing which may complicate the picture is that I'm planning to create a repo for each add-on in the current Share Extras. This is important as this is the level where we need to give people the ability to fork the code. Our SVN branches are not currently at the project level (rather, they are at the top level), but I believe they should be post-migration.

If there are updates to the add-ons such as the pdf.js viewer then I would suggest making them on Google Code, but could you raise an enhancement issue first so that we can coordinate these? I suspect we need to update to a more recent version of the library, but it sounds like you had other improvements as well, which sounds great.

Cheers,
Will

[Peter Löfgren]

2012/10/15 Will Abson <will....@gmail.com>:

> Hi Peter,
>
> I finally managed to get round to taking a look at the svn2git tool, and the
> docs certainly look good.
>
> The only thing which may complicate the picture is that I'm planning to
> create a repo for each add-on in the current Share Extras. This is important
> as this is the level where we need to give people the ability to fork the
> code. Our SVN branches are not currently at the project level (rather, they
> are at the top level), but I believe they should be post-migration.

That is correct approach. If this complicates migrating source
history, I think it is ok to just check in the latest version, source
history will still be available on Google code.
I also think that you can migrate projects on an activity/need basis.
To be honest I'm not sure if/when I have time to update ckeditor
control for example. Then better let it rest in its current location
until activated, this not to delay the move for other addons that are
more active.

>
> If there are updates to the add-ons such as the pdf.js viewer then I would
> suggest making them on Google Code, but could you raise an enhancement issue
> first so that we can coordinate these? I suspect we need to update to a more
> recent version of the library, but it sounds like you had other improvements
> as well, which sounds great.
>
> Cheers,
> Will

I've created Enhancement request 100
http://code.google.com/p/share-extras/issues/detail?id=100
I wanted to update to the latest pdf.js code (since it better
supported som pdf:s I needed to work), but ended up having to rewrite
much of the rendering, and while I was at it added search with Syntax
highlighting.
It all works well, just need a way to remove highlighting if pdf is
resized or search bar closed. If I find the time, lots of other things
to do right now (already three 4.2.a upgrades done).
Already checked in the code, thought it would be easier to review
then. Once on Github, we can get proper pull request :)

Cheers,
Peter