Switching from Subversion to Git

Switching from Subversion to Git

[Duncan Mak]

Hello Per,

Have you considered switching Kawa's code hosting from Subversion to Git(hub)?

--
Duncan.

Re: Switching from Subversion to Git

[Per Bothner]

On 08/28/2014 01:14 PM, Duncan Mak wrote:
> Hello Per,
>
> Have you considered switching Kawa's code hosting from Subversion to Git(hub)?

For now, I'm comfortable with Subversion.  I don't see a major benefit to
switching. (Also, we'd lose the nice sequential commit numbers.)  What do you
see as the major reason(s) to switch?

If we switch, I prefer Mercurial to Git, mainly because I'm more familiar with
it.  (Oracle uses Mercurial for their Java work.)

If we start getting more people working on and contributing to Kawa, then we
might consider switching to either Mercurial or Git.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Switching from Subversion to Git

[Duncan Mak]

On Thu, Aug 28, 2014 at 4:29 PM, Per Bothner <per@bothner.com> wrote:
> For now, I'm comfortable with Subversion.  I don't see a major benefit to
> switching. (Also, we'd lose the nice sequential commit numbers.)  What do
> you
> see as the major reason(s) to switch?

Microsoft recently moved their Typescript compiler from their own
hosting (Codeplex) to Github, and I've been following the activity.

Ever since the switch, I have found it much easier to follow the
discussions going on with the people working on the project. In fact,
because of the increased visibility, I've started contributing to the
project myself.

> If we switch, I prefer Mercurial to Git, mainly because I'm more familiar
> with it.  (Oracle uses Mercurial for their Java work.)
>
> If we start getting more people working on and contributing to Kawa, then we
> might consider switching to either Mercurial or Git.

I like Mercurial better than git as well, but as a place to build a
community, github really is quite advance. I suppose we can try
Bitbucket if you decide to switch.

Switching to one of the newer source control systems may be one way to
attract more people to contribute to Kawa.

-- 
Duncan.

Re: Switching from Subversion to Git

[mikel evins]

On Aug 28, 2014, at 3:50 PM, Duncan Mak <duncanmak@gmail.com> wrote:

> I like Mercurial better than git as well, but as a place to build a
> community, github really is quite advance. I suppose we can try
> Bitbucket if you decide to switch.

I like Bitbucket fine, too, and I keep some of my projects there. But github is the big watering hole.

Re: Switching from Subversion to Git

[Matthieu Vachon]

For me, it's more about switching to GitHub than to git. Switching to
git (or mercurial) only would bring not much overall to the current
process. The big advantages would come when switching to a hosted
collaboration platform. GitHub being the preferred for many peoples,
including me.

Here some advantages I see in switching to GitHub:

1. Better collaboration

GitHub is built around collaboration and is very good at it in my
opinion. The way Pull Requests works as many advantages, being able to
review and comment patches at a single place, putting together all the
necessary information of changes. Being close to the source code is
also a good plus being able to quickly point people to some part of
the source code. Also, issues management is a good plus since their
system is very clean and well made. Finally, not that important but
being markdown-aware everywhere make it something I like to work with.

Also, merging stuff into the main repository would require much less
work from you. People do pull requests, you review them, they make the
necessary changes and when ready, you only have to press a button and
the merge is made. This requires less manual work on your side giving
you more time for core development. There is not much patches right
now, so it might be a non-argument, but still :)

Using issues and labels efficiently, people could easily know some
easy pick to improve Kawa. This is a great way to get people to work
and to plan future additions.

2. Git (would also apply for Mercurial)

In general, I think git is far better and much pleasant to work with
than SVN. This is mainly a personal opinion, but I feel I'm not alone
thinking this. The branching model is damn good and fast and I always
enjoy working with it. In find nowadays that tooling is getting better
on git side than on SVN side. The fact that down time has much less
impact on git than SVN is also a good point for me.

Plus, I already worked on the SVN to git conversion. I maintain it on
GitHub and syncing it with SVN from time to time. This would reduce
the work needed to make the conversion.

3. Continuous integration

Travis CI being tied to Github, just this piece would be a good
improvement for a project like Kawa. Being able to test multiple
platforms after each push to the repository is enormous considering
the variety of Java implementation out there and versions supported
by Kawa. Moreover, pull requests could be directly tested prior being
merged in the master branch resulting in increased quality.

Again, I have made some work on this regarding Travis and Kawa code,
there would be not much work needed to activate this.

4. Better Feeling

Savannah and al is a good platform, but GitHub feels much better than
it. Most operations are web-based often resulting in less manual
operations. The UI is nicer and it gives a nice feeling for new people
to collaborate on the project. In my opinion, it is a more modern
platform, continuously updated and always offering more and more
features.

5. Exposure

As other mentioned already, and I also agree with them, their would be
more exposure possibility being on GitHub. There is a lot of
developers on this platform and I'm sure it would bring collaborators
in the future. I feel there is a massive amount of developer lurking
on GitHub. It would also make a good blog post maybe attracting some
traffic around the Kawa project.

6. Organization

A Kawa organization could be created on GitHub and more projects could
be hosted their. For example, the current (or a new) Kawa website
source repository could go their. This is something I would like to
improve in the future. At some point, documentation could be hosted
their also but that is another story.

The Kawa organization could also hosted some useful Kawa libraries
their giving them more exposure and usefulness. Here at work, we have
a bunch of useful of general Kawa modules that could be open-sourced.
These modules don't belongs to Kawa core but could help adoption of
Kawa by promoting re-usable common piece of software, something a la
Guava.

7. Releases

GitHub has a nice support for project releases tied to git tags. Kawa
releases could be hosted on GitHub. Everything would be in one place.

https://github.com/blog/1547-release-your-software

8. GitHub Pages & Wiki

GitHub pages could be used to host a new website for Kawa. Based on
Jekyll 2.0, a static site generator, the GitHub pages act solely as a
hosting point. This reduce the burden of maintenance. I never used it
myself, but releasing an minor update to a website is performed using
a single push to a git repository, again reducing to a really
low-level the maintenance of a website. Change, commit and push.

https://pages.github.com/

Moreover, all GitHub repository comes with a Wiki, enabling people to
put their their own tip and tricks and cookbooks for using Kawa and
stuff like this. Maybe not much gain but could be useful.

In the end, there is potentially some disadvantages in switching to
GitHub. But they should be minor and I don't see how they could
overcome the advantages.

Best regards,
Matt

On Thu, Aug 28, 2014 at 4:52 PM, mikel evins <mevins@me.com> wrote:
>
> On Aug 28, 2014, at 3:50 PM, Duncan Mak <duncanmak@gmail.com> wrote:
>
>> I like Mercurial better than git as well, but as a place to build a
>> community, github really is quite advance. I suppose we can try
>> Bitbucket if you decide to switch.
>
> I like Bitbucket fine, too, and I keep some of my projects there. But github is the big watering hole.
>
>

Re: Switching from Subversion to Git

[Per Bothner]

Thanks for your strong reasoning - sorry I've been tardy replying.

On 09/05/2014 09:58 AM, Matthieu Vachon wrote:
> For me, it's more about switching to GitHub than to git. Switching to
> git (or mercurial) only would bring not much overall to the current
> process. The big advantages would come when switching to a hosted
> collaboration platform. GitHub being the preferred for many peoples,
> including me.
>
> Here some advantages I see in switching to GitHub:
>
> 1. Better collaboration
>
> GitHub is built around collaboration and is very good at it in my
> opinion. The way Pull Requests works as many advantages, being able to
> review and comment patches at a single place, putting together all the
> necessary information of changes. Being close to the source code is
> also a good plus being able to quickly point people to some part of
> the source code. Also, issues management is a good plus since their
> system is very clean and well made. Finally, not that important but
> being markdown-aware everywhere make it something I like to work with.

> Also, merging stuff into the main repository would require much less
> work from you. People do pull requests, you review them, they make the
> necessary changes and when ready, you only have to press a button and
> the merge is made. This requires less manual work on your side giving
> you more time for core development. There is not much patches right
> now, so it might be a non-argument, but still :)

Suppose we enable this workflow, how would that change my current
workflow for changes that I make?  Right now, after I've tested a
patch, I just do 'svn ci'.  With "raw git" (or Mercurial) its
two commands, which is not noticably worse.  But if I have a trivial
fix I want to make, what is my workflow when using github?

> Using issues and labels efficiently, people could easily know some
> easy pick to improve Kawa. This is a great way to get people to work
> and to plan future additions.
>
> 2. Git (would also apply for Mercurial)
>
> In general, I think git is far better and much pleasant to work with
> than SVN. This is mainly a personal opinion, but I feel I'm not alone
> thinking this. The branching model is damn good and fast and I always
> enjoy working with it. In find nowadays that tooling is getting better
> on git side than on SVN side. The fact that down time has much less
> impact on git than SVN is also a good point for me.
>
> Plus, I already worked on the SVN to git conversion. I maintain it on
> GitHub and syncing it with SVN from time to time. This would reduce
> the work needed to make the conversion.
>
> 3. Continuous integration
>
> Travis CI being tied to Github, just this piece would be a good
> improvement for a project like Kawa. Being able to test multiple
> platforms after each push to the repository is enormous considering
> the variety of Java implementation out there and versions supported
> by Kawa. Moreover, pull requests could be directly tested prior being
> merged in the master branch resulting in increased quality.
>
> Again, I have made some work on this regarding Travis and Kawa code,
> there would be not much work needed to activate this.

This could certainly be a big plus.

> 4. Better Feeling
>
> Savannah and al is a good platform, but GitHub feels much better than
> it. Most operations are web-based often resulting in less manual
> operations. The UI is nicer and it gives a nice feeling for new people
> to collaborate on the project. In my opinion, it is a more modern
> platform, continuously updated and always offering more and more
> features.

Kawa is a GNU project (though a low-profile one), and politically I
want to be part of the GNU umbrella.  That is one advantage to Savannah.


> 5. Exposure
>
> As other mentioned already, and I also agree with them, their would be
> more exposure possibility being on GitHub. There is a lot of
> developers on this platform and I'm sure it would bring collaborators
> in the future. I feel there is a massive amount of developer lurking
> on GitHub. It would also make a good blog post maybe attracting some
> traffic around the Kawa project.

That's not clear to be.  With millions of Github projects, I'd be
surprised if getting noticed would be any easier.

> 6. Organization
>
> A Kawa organization could be created on GitHub and more projects could
> be hosted their. For example, the current (or a new) Kawa website
> source repository could go their. This is something I would like to
> improve in the future. At some point, documentation could be hosted
> their also but that is another story.

For now I'd like to keep at least the Kawa web pages on gnu.org, and
use the existing framework.  (Not to deny that the webpages need work -
to start the home page needs to be simplified and the Features page
needs to be updated and punchier.)

I do own the kawa-lang.org domain.  If at some point we move the website,
I'd like to use that.

> The Kawa organization could also hosted some useful Kawa libraries
> their giving them more exposure and usefulness. Here at work, we have
> a bunch of useful of general Kawa modules that could be open-sourced.
> These modules don't belongs to Kawa core but could help adoption of
> Kawa by promoting re-usable common piece of software, something a la
> Guava.

> 7. Releases
>
> GitHub has a nice support for project releases tied to git tags. Kawa
> releases could be hosted on GitHub. Everything would be in one place.
>
> https://github.com/blog/1547-release-your-software

Kawa source tarballs are a bit more complex, following GNU standards.
Can the Github release mechanism handle that?  I see you can add extra
"assets" (such as pre-generated files), but it's not clear how to do
that automatically .

>
> 8. GitHub Pages & Wiki
>
> GitHub pages could be used to host a new website for Kawa. Based on
> Jekyll 2.0, a static site generator, the GitHub pages act solely as a
> hosting point. This reduce the burden of maintenance. I never used it
> myself, but releasing an minor update to a website is performed using
> a single push to a git repository, again reducing to a really
> low-level the maintenance of a website. Change, commit and push.
>
> https://pages.github.com/
>
> Moreover, all GitHub repository comes with a Wiki, enabling people to
> put their their own tip and tricks and cookbooks for using Kawa and
> stuff like this. Maybe not much gain but could be useful.
>
> In the end, there is potentially some disadvantages in switching to
> GitHub. But they should be minor and I don't see how they could
> overcome the advantages.

I have no experience using GitHub (except some simple browsing) so
we'd need volunteer(s) to do it.

If we switch to GitHub for bug-tracking (which I assume you wuld recommend?)
then we have problem what to do with existing issues.  I assume it would
be too difficult to migrate the existing issues.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Switching from Subversion to Git

[Matthieu Vachon]

On Mon, Sep 22, 2014 at 5:15 PM, Per Bothner <per@bothner.com> wrote:
> Thanks for your strong reasoning - sorry I've been tardy replying.

No problem, it's not an urgent topic and more a long-standing discussion :)

>
> Suppose we enable this workflow, how would that change my current
> workflow for changes that I make?  Right now, after I've tested a
> patch, I just do 'svn ci'.  With "raw git" (or Mercurial) its
> two commands, which is not noticably worse.  But if I have a trivial
> fix I want to make, what is my workflow when using github?
>

For the development you are doing yourself, I would not change your
workflow at all. Simply commit your changes and then push on the
remote git repository. I don't think a formal review style workflow
would bring much for Kawa project as it is right now. Mainly because
you are the main contributor, so you would probably review your own
patches which does not have much sense.

The different workflow I mentioned earlier would be reserved for
patches currently submitted on the mailing list or via the bug
tracker. Here the workflow that is most commonly used on github:

 1. Developer fork Kawa (which is a personal clone with write access)
and creates a feature or fix branch (feature-optimize-switch or
fix-int-conversion, for example).
 2. Developer make some commits in git and push to his forked repository.
 3. Once ready, developer, using GitHub interface, creates a Pull
Request. In words, it's a way to ask you, the manager of the project,
to merge fix-int-conversion branch from forked repository into master
branch of official Kawa repository.
 4. Travis continuous integration runs the whole test suite using the
developer's branch, telling directly in the web UI if the test suite
passes or not.
 4. Being notified, you review the pull request in the web interface,
making comments and asking for changes.
 5. Developer make the changes you asked for and push a new version.
 6. Tests are run again.
 7. You are satisfy with the patch, you simply press merge in the web UI.

>
> Kawa is a GNU project (though a low-profile one), and politically I
> want to be part of the GNU umbrella.  That is one advantage to Savannah.
>

I don't now much about GNU project requirements, so it cannot see what
would be the consequences of moving to GitHub. I read they have hard
policy regarding usages of Free Software. Don't know if this is true
also for the hosting platform.  I guess it's a potential show-stopper.

>
> That's not clear to be.  With millions of Github projects, I'd be
> surprised if getting noticed would be any easier.
>

I agree, maybe I was over optimistic at time of writing :) Overall, I
still think it would be a good move for the exposure of the project.
Maybe just not as big as I have implied.

>
> For now I'd like to keep at least the Kawa web pages on gnu.org, and
> use the existing framework.  (Not to deny that the webpages need work -
> to start the home page needs to be simplified and the Features page
> needs to be updated and punchier.)
>
> I do own the kawa-lang.org domain.  If at some point we move the website,
> I'd like to use that.
>

I understand. The point was mainly to show some possibilities offered
by GitHub. On a side note, configuring a custom domain name with
GitHub Pages seems possible.

>
> Kawa source tarballs are a bit more complex, following GNU standards.
> Can the Github release mechanism handle that?  I see you can add extra
> "assets" (such as pre-generated files), but it's not clear how to do
> that automatically .
>

Hard to tell, I never did a release using GitHub mechanism myself. I
will try to test this feature this week on a test repository to see
how it works and to what extend it could be automated.

>
> I have no experience using GitHub (except some simple browsing) so
> we'd need volunteer(s) to do it.
>

I'm all in to help with this. Again, some conversion work and
configuration is already done and working.

> If we switch to GitHub for bug-tracking (which I assume you wuld recommend?)
> then we have problem what to do with existing issues.  I assume it would
> be too difficult to migrate the existing issues.
>

Indeed, I would recommend it all way long. If there is a web API for
Savannah, which I doubt after my little research, it should be
possible to have something to migrate issues without too much problem.
It almost 100% sure that it would not be a 1:1 mapping, but seeing the
GitHub API for issues (https://developer.github.com/v3/issues/), I
hope that a lot could be achieved.

Even without a Savannah web API for fetching issues, making a small
bot crawling Savannah issues and exporting them to a sort of exchange
format could be a fun "project" for someone wanting to learn Kawa.
With the issues formatted into JSON for example, it would then be easy
to import them into GitHub directly using their web API.

Maybe a volunteer will rise for this :) But if not, I'm willing to
make this happen.

If their is something I can do to help you in your decision, I'm not far :)

In the end, you are the one taking the decision and I will respect it,
whatever it is :D

Best regards,
Matt

Re: Switching from Subversion to Git

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 913 bytes --]

Hello,

> ... Here the workflow that is most commonly used on github:...

I am not using kawa, but I am 'lazilly' following the list [I use guile].  On this
git related subject and thread, I'd like to recommend a git link I liked very much
when I switched to git for my own projects and for helping projects related to guile
[I'am currently trying to help, working on g-wrap, guile-cairo, guile-gnome and
guile-clutter]

The link is this one:

	http://nvie.com/posts/a-successful-git-branching-model/

> > Kawa is a GNU project (though a low-profile one), and politically I
> > want to be part of the GNU umbrella.  That is one advantage to Savannah.

I strongly believe that savannah is a much much better place for gnu projects, but
it could be a subjective opinion.  Many people complained, on guile's lists about
github not being free... and I like savannah.

My 2c :)

Cheers,
David

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 173 bytes --]

Re: Switching from Subversion to Git

[mikel evins]

On Sep 24, 2014, at 12:39 AM, David Pirotte <david@altosw.be> wrote:

> Hello,
> 
>> ... Here the workflow that is most commonly used on github:...
> 
> I am not using kawa, but I am 'lazilly' following the list [I use guile].  On this
> git related subject and thread, I'd like to recommend a git link I liked very much
> when I switched to git for my own projects and for helping projects related to guile
> [I'am currently trying to help, working on g-wrap, guile-cairo, guile-gnome and
> guile-clutter]
> 
> The link is this one:
> 
> 	http://nvie.com/posts/a-successful-git-branching-model/

I'll second your endorsement of this model. I've found it very helpful, and used it to help bring a small team up to speed on Mercurial, whose differences from Git are minor.

Git and Mercurial can be unexpectedly hard for experienced programmers to adjust to. They're not that hard to learn or understand, but a large fraction of new users seem to go through a phase where they just balk, and don't get how the VCS works or how they're supposed to use it. It was my experience that this reaction went away after a week or so with a little handholding, after which competence and enthusiasm rose rapidly.

DVCSes are not perfect. Nothing is. But there are two things that I find compelling about them: when compared to Subversion they are very fast for most operations, and, more importantly, when using a DVCS, you *always* have access to revision control. 

The CVS and Perforce and Subversion model is that there is a central repository, and you check things into it and out of it. The main disadvantage of this model is that if your net connection goes down or if there's a problem with the server, you lose access to revision control until the problem is resolved. That doesn't happen all that often, but its very rarity makes it even more of a pain when it does happen, because you most likely don't have ready-made strategies for dealing with it.

With a DVCS like Git or Mercurial, losing the network or the server has no effect on your access to revision control. You can continue to commit changes just as if the connection were still sound.

In order to make that work, DVCSes introduce a small extra level of complexity: the act of committing changes and the act of pushing them to a remote server become separate things. Similarly, getting changes from the remote server is not the same thing as checking them out into your working directory; there's an extra step. It can take a week or so to get used to that difference.

Once past that difference, though, the safety and convenience of having the VCS always available, even while you're out of network connectivity, is so nice that it's hard to give it up after you've experienced it.

Re: Switching from Subversion to Git

[Matthieu Vachon]

On Wed, Sep 24, 2014 at 1:39 AM, David Pirotte <david@altosw.be> wrote:
> Hello,
> [I'am currently trying to help, working on g-wrap, guile-cairo, guile-gnome and
> guile-clutter]
>
> The link is this one:
>
>         http://nvie.com/posts/a-successful-git-branching-model/
>

Thank you for the link, this is indeed one of the reference for git
branching model. Here a tutorial I found recently made by Atlassian.
It compares four different possible git branching models with one of
them being the one you linked (referred as gitflow workflow in the
post).

https://www.atlassian.com/git/tutorials/comparing-workflows

It also includes other information, mainly focused for people coming
from the SVN world:

https://www.atlassian.com/git/tutorials/syncing

And to migrate from SVN:

https://www.atlassian.com/git/tutorials/migrating-overview

>> > Kawa is a GNU project (though a low-profile one), and politically I
>> > want to be part of the GNU umbrella.  That is one advantage to Savannah.
>
> I strongly believe that savannah is a much much better place for gnu projects, but
> it could be a subjective opinion.  Many people complained, on guile's lists about
> github not being free... and I like savannah.
>

This is completely true. GitHub is "free" for public projects, just
not open sourced and GPL licensed.

This is completely personal, but I never understood complaints about
the point of the being "free" (as in open sourced). Maybe because I'm
too "young" to have lived this debate  :)

> My 2c :)

Thank you for joining the discussion.

Matt

Re: Switching from Subversion to Git

[Per Bothner]

I'm certainly open to switching from Subversion to Git or Mercurial,
if that would make a difference.  (The main hesitation is deciding
between Git or Mercurial ... I have experience with Mercurial, and most
people agree it is a little simpler and cleaner; however, Git is much
more popular.)

However, it's been suggested that the advantage in switching to Git
is relatively minor unless we also switch to an integrated hosting site,
specifically GitHub.  That is somewhat problematical because GitHub's
use of closed source.  Note this is not only the case for "enterprise
add-one" functionality - even the Windows github client (which is the
recommended way to work with github on Windows) is closed-source.

There are alternatives.  For example GitLab Community Edition.  But the
hosting on gitlab.com runs the Enterprise Edition, plus repositories
have a "soft limit" (whatever that means) of 1GB.

We can of course move to git on Savannah, but it's not as featureful as GitHub.

Or a volunteer could upgrade Savannah to GitLab community edition ...
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Switching from Subversion to Git

[Helmut Eller]

On Thu, Sep 25 2014, Per Bothner wrote:

> We can of course move to git on Savannah, but it's not as featureful
> as GitHub.

This seems reasonable to me.  People who like GitHub could then easily
create mirrors, run Travis CI and publish patches on GitHub.  I wouldn't
be surprised if GitHub fans do that even if you move the official repo
to GitLab.

Helmut

Fwd: Switching from Subversion to Git

[Matthieu Vachon]

> On Thu, Sep 25 2014, Per Bothner wrote:
>
> use of closed source.  Note this is not only the case for "enterprise
> add-one" functionality - even the Windows github client (which is the
> recommended way to work with github on Windows) is closed-source.
>

Indeed, this could be see as a problem. For the recommended way to
work with GitHub on Windows, I disagree, I'm using msysGit on Windows
coupled with msys2 tools and there is everything in there to work
efficiently from the terminal. For merge conflicts, msysGit connects
gracefully to TortoiseDiff which I find the best GUI conflict resolver
on Windows (personal opinion, of course).

>
> There are alternatives.  For example GitLab Community Edition.  But the
> hosting on gitlab.com runs the Enterprise Edition, plus repositories
> have a "soft limit" (whatever that means) of 1GB.
>

GitLab is really great also. Not as featureful as GitHub ... yet. The
development is thrilling and the guys there are doing a pretty good
job improving the tool at each release. Lots of the points I brought
to the table for GitHub as still valid for GitLab. We use the
community edition in the company and are more than happy with it.
There is small problems here and there, but nothing major.

But as you mentioned, the hosting site uses the Enterprise edition,
which is closed source. This could be seen as a similar problem as
GitHub (to a less extent in my opinion).

>
> We can of course move to git on Savannah, but it's not as featureful as GitHub.
>
> Or a volunteer could upgrade Savannah to GitLab community edition ...

I would be more than happy to do it, however, before putting effort in
this, I want to be sure that's something really wanted by the
community. Helmut is (unless I'm wrong) one of the top most
contributor right after you Per. Reading is follow-up email, he would
be more inclined to switch to git but still host everything on
Savannah. This would also be a viable advancement for the project I
think. I will answer Helmut's response before continuing.

> On Fri, Sep 26, 2014 at 2:42 AM, Helmut Eller <eller.helmut@gmail.com> wrote:
>
>> We can of course move to git on Savannah, but it's not as featureful
>> as GitHub.
>
> This seems reasonable to me.  People who like GitHub could then easily
> create mirrors, run Travis CI and publish patches on GitHub.  I wouldn't
> be surprised if GitHub fans do that even if you move the official repo
> to GitLab.

Indeed, once source is on git, having a mirror on GitHub (or
elsewhere) would be quite easy. I think one of the main point of the
mirror on GitHub is to have a working Travis CI setup. It's not the
point of being a fan of GitHub, it's more to get a better quality for
the Kawa project in general by running the CI on multiple Java
platforms at once after each push. If it would be feasible with GitLab
(or Savannah), I would do the work to make it happen. Sadly, Travis CI
is too tightly integrated with GitHub, I'm not even sure they will
make the abstraction one day :( There is other CI platforms, but the
setup is almost always more complicated and constraints (hosting,
administration, configuration) can be very hard.

Hence, whether the decision, I will maintain my mirror mainly to
profit of Travis CI integration. But I will work with the chosen
platform to send patches and report issues.

That being said, I do not want to force any decision here. Maybe doing
small steps would be better. Like switching to git but still using
Savannah for hosting. Maybe making the switch to another hosting
platform later on. Here a summary of what could happen next:

 * Statu quo (continue with SVN, hosting on Savannah)
 * Switch to git, hosting on Savannah
 * Switch to git, hosting on GitLab
 * Switch to mercurial, hosting on ?!? (does Savannah offers something
for this?, BitBucket)

Other possibilities I have missed?

Regards,
Matt

Re: Fwd: Switching from Subversion to Git

[Per Bothner]

On 10/03/2014 11:04 PM, Matthieu Vachon wrote:
>> On Thu, Sep 25 2014, Per Bothner wrote:

>> Or a volunteer could upgrade Savannah to GitLab community edition ...
>
> I would be more than happy to do it, however, before putting effort in
> this, I want to be sure that's something really wanted by the
> community.

It's not just the Kawa community, but the greater Savannah (and GNU) communities.
Switching Savannah to GitLab would need a general buy-in from the Savannah
communities.  In practice, I think one would need to parallel-install both
GitLab and Savane "interfaces".  This is a project requiring a major planning
and commitment.

>Helmut is (unless I'm wrong) one of the top most
> contributor right after you Per.

Helmut is the top contributor of bug reports, thus indirectly cause me
to make changes to a lot of code ...  He hasn't contributed a lot
of actual code to Kawa itself.

>   * Statu quo (continue with SVN, hosting on Savannah)

Actually status quo uses sourcesware.org for SVN hosting (and emails).
Sourceware is used for various projects that were maintained by Cygnus
and Cygnus people.  (Cygnus was acquired by Red Hat in 2000.)  Kawa was
originally developed when I worked at Cygnus.

Savannah (or the GNU infrastructure more generally) is used for the bug tracker,
web pages, and the ftp releases.

Regardless, it would be reasonable to migrate off sourceware, but it's not a
priority in itself, only if we at the same time migrate to git or mercurial.

  * Switch to mercurial, hosting on ?!? (does Savannah offers something
for this?, BitBucket)

Savannah supports both git and Mercurial.  (The web page support uses CVS ...)
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Fwd: Switching from Subversion to Git

[Per Bothner]

[Going back to a discussion from October 2014.]

While I'm reasonably content with Subversion, two things have happened to
increase my readiness for a switch to Git:

(1) I created a new project on GitHub, so I've been using git more:

https://github.com/PerBothner/DomTerm

(2) More high-profile GNU projects have or will soon switch to Git:
emacs, gcc, gdb

Emacs specifically is hosted on Savannah:
http://git.savannah.gnu.org/cgit/emacs.git

If we still have a volunteer to set up a git repository on Savannah
for Kawa, that would be welcome.  I'm hoping it should be possible to
initially set it up a git mirror, and then after testing switching it
over to be the master.  (That seems to be the plan for gcc - to switch
over an existing repository.)
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Fwd: Switching from Subversion to Git

[Matthieu Vachon]

Note: Re-posting on mailing-list with plain text, sorry.

Hi Per,

Sure I still volunteer to make it happen. As said earlier, I already
performed SVN conversion to git and it's hosted at
https://github.com/maoueh/kawa-fork. Could you take a look and ensure
that is correct with you. It would then be a simple matter of pushing
the SVN mirror to the new Savannah git repository.

It is not fully up-to-date as I had problem syncing with SVN. It
stopped with some weird errors on revision 8527. So, current `master`
branch (equivalent to `trunk`) is at revision 8526. Will try to debug
syncing problem when I find more time.

Is a manual SVN mirror enough or are you aiming more to an fully
automatic mirror? Do you want a bi-directional mirror (git push syncs
to SVN and SVN commit pushes to git) or a one way would be ok (SVN to
git only)?

Regards,
Matt

On Mon, Aug 24, 2015 at 3:01 PM Per Bothner <per@bothner.com> wrote:
>
> [Going back to a discussion from October 2014.]
>
> While I'm reasonably content with Subversion, two things have happened to
> increase my readiness for a switch to Git:
>
> (1) I created a new project on GitHub, so I've been using git more:
>
> https://github.com/PerBothner/DomTerm
>
> (2) More high-profile GNU projects have or will soon switch to Git:
> emacs, gcc, gdb
>
> Emacs specifically is hosted on Savannah:
> http://git.savannah.gnu.org/cgit/emacs.git
>
> If we still have a volunteer to set up a git repository on Savannah
> for Kawa, that would be welcome.  I'm hoping it should be possible to
> initially set it up a git mirror, and then after testing switching it
> over to be the master.  (That seems to be the plan for gcc - to switch
> over an existing repository.)
> --
>         --Per Bothner
> per@bothner.com   http://per.bothner.com/

Re: Fwd: Switching from Subversion to Git

[Per Bothner]

On 08/26/2015 04:35 PM, Matthieu Vachon wrote:
> Note: Re-posting on mailing-list with plain text, sorry.
>
> Hi Per,
>
> Sure I still volunteer to make it happen. As said earlier, I already
> performed SVN conversion to git and it's hosted at
> https://github.com/maoueh/kawa-fork. Could you take a look and ensure
> that is correct with you. It would then be a simple matter of pushing
> the SVN mirror to the new Savannah git repository.

It looks ok.  It would look different on Savannah.
http://git.savannah.gnu.org/cgit/emacs.git

Note that since your git clone I've created two branches
(invoke, plus callcc, which is branched off invoke).
That might change things.

> It is not fully up-to-date as I had problem syncing with SVN. It
> stopped with some weird errors on revision 8527. So, current `master`
> branch (equivalent to `trunk`) is at revision 8526. Will try to debug
> syncing problem when I find more time.
>
> Is a manual SVN mirror enough or are you aiming more to an fully
> automatic mirror? Do you want a bi-directional mirror (git push syncs
> to SVN and SVN commit pushes to git) or a one way would be ok (SVN to
> git only)?

It depends on the goal.  If the goal is to switch over to git as the
primary repository, then the mirroring doesn't have to be full.
In fact we don't *need* automatic mirroring at all - its just nice.

At the very list we need to git repository on Savannah.  It doesn't
have to be a mirror of the svn repository, though that would be nice.
It's acceptable for it to just be a static snapshot, or one that can
be manually brought up to date - only needed during the evaluation period.

If after the evaluation period we decide to make the switch, then we
freeze the old repository (easy as long as I'm the only committer).
Then we do a final update from the old repository, and then after
some testing we declare the new repository as the primary one.

Of course if bi-directional mirroring is easy to set up, I won't
say no :-)
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Fwd: Switching from Subversion to Git

[Matthieu Vachon]

Hi Per,

Here the steps I propose for this issue:

 1. Take necessary actions with Savannah to create git repository
where you get write access to it. I will assume url of connection to
be `bothner@git.sv.gnu.org:/srv/git/kawa.git`.

 2. At this point, you have two choices to retrieve svn to git clone.
You either use my uploaded already built svn to git clone or create a
new one from scratch. Indeed, svn metadata is stored on the local
computer and cannot (to my knowledge), be shared easily. Only way I
know is to zip whole git repository and share it or clone it back from
scratch.

      1. If you download my own already built and zip repository, do
the following:

              cd ~/downloads
              # Download zip file from  to kawa-git.zip

              cd ~/work/
              unzip ~/downloads/kawa-git.zip
              # Zip contains a single directory named kawa-git

      2. If you choose to do yourself a new svn to git clone (doing
directly `git svn clone -s svn://sourceware.org/svn/kawa kawa-git`
never work for me hence the local svn mirror in kawa-svn):

              cd ~/work
              svnadmin create kawa-svn
              printf '#!/bin/sh\nexit 0;\n' > kawa-svn/hooks/pre-revprop-change
              svnsync init file:///home/bother/work/kawa-svn
svn://sourceware.org/svn/kawa # Use correct absolute path to svn
mirror file:///....
              svnsync sync file:///home/bother/work/kawa-svn # Use
correct absolute path to svn mirror file:///....
              # Around 45 minutes

             git svn clone -s -r 1:8526
file:///home/bother/work/kawa-svn kawa-git # Use correct absolute path
to svn mirror file:///....
             # Around 180 minutes

 3. Then you add Savannah as a new remote in your git repository

              cd ~/work/kawa-git
              git remote add upstream bothner@git.sv.gnu.org:/srv/git/kawa.git

 4. Push the git branches you need:

              git push upstream master
              git checkout -b invoke origin/invoke
              git push upstream invoke
              git checkout -b callcc origin/callcc
              git push upstream callcc

 5. Work with git now instead of SVN by making some commits and then
sync back to svn (theory from here as I did not test those commands):

               # Make some git commits in master branch
               git svn dcommit
               git push upstream master

The sync back command (i.e. `git svn dcommit`) rewrites git sha1
commit to add SVN revision number. That's why you must first commit
back to SVN and then pushing to git remote. Pushing to git first and
then doing `git svn dcommit` would require next push to be a force
push (git push origin -f master) since parts of the history was
rewritten by `git svn dcommit`.

You could also make some SVN commits and then update your local git
svn clone with `git svn fetch` (or `git svn rebase` if you had git
commits not synced back to SVN). Moreover, different branch (invoke
and callcc) should work. You should also be able to work in them in
git and push back commits to svn respective branches. I'm not sure
about merging however. Merging might be better done in SVN and then
sync back to git afterward.

All this information (and much more) is all described at
https://git-scm.com/book/en/v1/Git-and-Other-Systems-Git-and-Subversion.
It's a pretty good reference page.

Automatic mirror is probably not needed here since you are the only
one with write access. You can simply work only in git, and push back
commits to SVN to keep them in sync. Don't hesitate to ask anything if
steps are unclear.

Regards,
Matt

On Wed, Aug 26, 2015 at 10:50 PM Per Bothner <per@bothner.com> wrote:
>
>
>
> On 08/26/2015 04:35 PM, Matthieu Vachon wrote:
> > Note: Re-posting on mailing-list with plain text, sorry.
> >
> > Hi Per,
> >
> > Sure I still volunteer to make it happen. As said earlier, I already
> > performed SVN conversion to git and it's hosted at
> > https://github.com/maoueh/kawa-fork. Could you take a look and ensure
> > that is correct with you. It would then be a simple matter of pushing
> > the SVN mirror to the new Savannah git repository.
>
> It looks ok.  It would look different on Savannah.
> http://git.savannah.gnu.org/cgit/emacs.git
>
> Note that since your git clone I've created two branches
> (invoke, plus callcc, which is branched off invoke).
> That might change things.
>
> > It is not fully up-to-date as I had problem syncing with SVN. It
> > stopped with some weird errors on revision 8527. So, current `master`
> > branch (equivalent to `trunk`) is at revision 8526. Will try to debug
> > syncing problem when I find more time.
> >
> > Is a manual SVN mirror enough or are you aiming more to an fully
> > automatic mirror? Do you want a bi-directional mirror (git push syncs
> > to SVN and SVN commit pushes to git) or a one way would be ok (SVN to
> > git only)?
>
> It depends on the goal.  If the goal is to switch over to git as the
> primary repository, then the mirroring doesn't have to be full.
> In fact we don't *need* automatic mirroring at all - its just nice.
>
> At the very list we need to git repository on Savannah.  It doesn't
> have to be a mirror of the svn repository, though that would be nice.
> It's acceptable for it to just be a static snapshot, or one that can
> be manually brought up to date - only needed during the evaluation period.
>
> If after the evaluation period we decide to make the switch, then we
> freeze the old repository (easy as long as I'm the only committer).
> Then we do a final update from the old repository, and then after
> some testing we declare the new repository as the primary one.
>
> Of course if bi-directional mirroring is easy to set up, I won't
> say no :-)
> --
>         --Per Bothner
> per@bothner.com   http://per.bothner.com/

Re: Fwd: Switching from Subversion to Git

[Matthieu Vachon]

Oups, forgot to put download link to pre-built svn to git repository:

http://www.filedropper.com/kawa-git

I also uploaded it to my Google Driver and could share the link
privately for it if you prefer.

On Tue, Sep 15, 2015 at 12:54 PM, Matthieu Vachon
<matthieu.o.vachon@gmail.com> wrote:
> Hi Per,
>
> Here the steps I propose for this issue:
>
>  1. Take necessary actions with Savannah to create git repository
> where you get write access to it. I will assume url of connection to
> be `bothner@git.sv.gnu.org:/srv/git/kawa.git`.
>
>  2. At this point, you have two choices to retrieve svn to git clone.
> You either use my uploaded already built svn to git clone or create a
> new one from scratch. Indeed, svn metadata is stored on the local
> computer and cannot (to my knowledge), be shared easily. Only way I
> know is to zip whole git repository and share it or clone it back from
> scratch.
>
>       1. If you download my own already built and zip repository, do
> the following:
>
>               cd ~/downloads
>               # Download zip file from  to kawa-git.zip
>
>               cd ~/work/
>               unzip ~/downloads/kawa-git.zip
>               # Zip contains a single directory named kawa-git
>
>       2. If you choose to do yourself a new svn to git clone (doing
> directly `git svn clone -s svn://sourceware.org/svn/kawa kawa-git`
> never work for me hence the local svn mirror in kawa-svn):
>
>               cd ~/work
>               svnadmin create kawa-svn
>               printf '#!/bin/sh\nexit 0;\n' > kawa-svn/hooks/pre-revprop-change
>               svnsync init file:///home/bother/work/kawa-svn
> svn://sourceware.org/svn/kawa # Use correct absolute path to svn
> mirror file:///....
>               svnsync sync file:///home/bother/work/kawa-svn # Use
> correct absolute path to svn mirror file:///....
>               # Around 45 minutes
>
>              git svn clone -s -r 1:8526
> file:///home/bother/work/kawa-svn kawa-git # Use correct absolute path
> to svn mirror file:///....
>              # Around 180 minutes
>
>  3. Then you add Savannah as a new remote in your git repository
>
>               cd ~/work/kawa-git
>               git remote add upstream bothner@git.sv.gnu.org:/srv/git/kawa.git
>
>  4. Push the git branches you need:
>
>               git push upstream master
>               git checkout -b invoke origin/invoke
>               git push upstream invoke
>               git checkout -b callcc origin/callcc
>               git push upstream callcc
>
>  5. Work with git now instead of SVN by making some commits and then
> sync back to svn (theory from here as I did not test those commands):
>
>                # Make some git commits in master branch
>                git svn dcommit
>                git push upstream master
>
> The sync back command (i.e. `git svn dcommit`) rewrites git sha1
> commit to add SVN revision number. That's why you must first commit
> back to SVN and then pushing to git remote. Pushing to git first and
> then doing `git svn dcommit` would require next push to be a force
> push (git push origin -f master) since parts of the history was
> rewritten by `git svn dcommit`.
>
> You could also make some SVN commits and then update your local git
> svn clone with `git svn fetch` (or `git svn rebase` if you had git
> commits not synced back to SVN). Moreover, different branch (invoke
> and callcc) should work. You should also be able to work in them in
> git and push back commits to svn respective branches. I'm not sure
> about merging however. Merging might be better done in SVN and then
> sync back to git afterward.
>
> All this information (and much more) is all described at
> https://git-scm.com/book/en/v1/Git-and-Other-Systems-Git-and-Subversion.
> It's a pretty good reference page.
>
> Automatic mirror is probably not needed here since you are the only
> one with write access. You can simply work only in git, and push back
> commits to SVN to keep them in sync. Don't hesitate to ask anything if
> steps are unclear.
>
> Regards,
> Matt
>
> On Wed, Aug 26, 2015 at 10:50 PM Per Bothner <per@bothner.com> wrote:
>>
>>
>>
>> On 08/26/2015 04:35 PM, Matthieu Vachon wrote:
>> > Note: Re-posting on mailing-list with plain text, sorry.
>> >
>> > Hi Per,
>> >
>> > Sure I still volunteer to make it happen. As said earlier, I already
>> > performed SVN conversion to git and it's hosted at
>> > https://github.com/maoueh/kawa-fork. Could you take a look and ensure
>> > that is correct with you. It would then be a simple matter of pushing
>> > the SVN mirror to the new Savannah git repository.
>>
>> It looks ok.  It would look different on Savannah.
>> http://git.savannah.gnu.org/cgit/emacs.git
>>
>> Note that since your git clone I've created two branches
>> (invoke, plus callcc, which is branched off invoke).
>> That might change things.
>>
>> > It is not fully up-to-date as I had problem syncing with SVN. It
>> > stopped with some weird errors on revision 8527. So, current `master`
>> > branch (equivalent to `trunk`) is at revision 8526. Will try to debug
>> > syncing problem when I find more time.
>> >
>> > Is a manual SVN mirror enough or are you aiming more to an fully
>> > automatic mirror? Do you want a bi-directional mirror (git push syncs
>> > to SVN and SVN commit pushes to git) or a one way would be ok (SVN to
>> > git only)?
>>
>> It depends on the goal.  If the goal is to switch over to git as the
>> primary repository, then the mirroring doesn't have to be full.
>> In fact we don't *need* automatic mirroring at all - its just nice.
>>
>> At the very list we need to git repository on Savannah.  It doesn't
>> have to be a mirror of the svn repository, though that would be nice.
>> It's acceptable for it to just be a static snapshot, or one that can
>> be manually brought up to date - only needed during the evaluation period.
>>
>> If after the evaluation period we decide to make the switch, then we
>> freeze the old repository (easy as long as I'm the only committer).
>> Then we do a final update from the old repository, and then after
>> some testing we declare the new repository as the primary one.
>>
>> Of course if bi-directional mirroring is easy to set up, I won't
>> say no :-)
>> --
>>         --Per Bothner
>> per@bothner.com   http://per.bothner.com/

Re: Switching from Subversion to Git

[mikel evins]

On Aug 28, 2014, at 3:29 PM, Per Bothner <per@bothner.com> wrote:

> On 08/28/2014 01:14 PM, Duncan Mak wrote:
>> Hello Per,
>> 
>> Have you considered switching Kawa's code hosting from Subversion to Git(hub)?
> 
> For now, I'm comfortable with Subversion.  I don't see a major benefit to
> switching. (Also, we'd lose the nice sequential commit numbers.)  What do you
> see as the major reason(s) to switch?
> 
> If we switch, I prefer Mercurial to Git, mainly because I'm more familiar with
> it.  (Oracle uses Mercurial for their Java work.)
> 
> If we start getting more people working on and contributing to Kawa, then we
> might consider switching to either Mercurial or Git.

I've used all of them quite a bit. I use git day-to-day nowadays.

The primary advantages of git over Subversion, in my experience,are:

- when the repository server is down, or the network is unavailable, there is no interruption in your ability to use revision control.

- branching and merging are significantly easier and safer than with Subversion.

- git's faster.


The only advantage of git over Mercurial, as far as I can see, is that github uses git. Github is useful enough by itself to be a reason to consider using git. It's the reason I use git; without github in the equation, I prefer Mercurial.

git is generally faster than Mercurial, but we're talking about the difference between a few millseconds and a few tens of milliseconds in a typical interaction, so git's speed advantage over Mercurial is usually imperceptible.

There are disadvantages to switching from Subversion to git or mercurial. Sequential revision numbering is one, though as a practical matter I don't miss them. More important is that using a distributed revision control system is actually different enough to require some relearning, even is--as is typical--a project works from a de facto central repository.  You have to get used to the fact that, for example, checking your code in does not mean anyone else can see your changes. You must also push your changes to the shared repository. Similarly, pulling changes does not necessarily mean you'll see them locally; it depends on whether you normally use a form of the command that also checks them out into your local working directory.

All of this is easy enough to adapt to, but adaptation is required.