Moving to git from svn?

[tomjenkinson]

Hi,

We are mooting the point of migrating the source code repository from svn over to the current flavour of the month, git.

The advantages seem to be that it is much easier to support patches from the community and potentially moving forward greater availability of tooling support.

Disadvantages would be that we would most likely do a top-skim so for a while the history would be in two places.

Does anyone have any particular experience with svn/git migration and can help to argue the case to move or not?

Tom

[jaikiran]

This might help a bit http://blog.emmanuelbernard.com/2010/05/git-how-my-life-has-improved-since-last-month-when-i-used-svn/

[tomjenkinson]

Thanks Jaikiran, that article makes some compelling arguments around maintainance branches etc - much appreciated!

[adinn]

Tom Jenkinson wrote:

Disadvantages would be that we would most likely do a top-skim so for a while the history would be in two places.

Does anyone have any particular experience with svn/git migration and can help to argue the case to move or not?

I successfully moved the Byteman repo from SVN to git using svn2git, preserving all history. There were two slightly tricky bits:

• getting the authors names right -- you need to remap all the names which have been used during checkin otherwise the convert fails. so you might end up redoing the convert a few times beforeyou get them all. this is annoing as the conversion takes quite a long time.
• pruning branches/tags which had been deleted and then recreated in SVN -- overwritten branches/tags appear with names like 4.1.3.Final@33957. all you need to do is delete these branches/tags after conversion andbefore uploading the lcoal converted repo into github

I think it is well worth doing though. git makes collaboration much much easier both inside and outside the JBoss(TS) team.

[tomjenkinson]

Hi Andrew,

Thanks for the feedback. I am a bit concerned about how long a conversion might take as the transactions repo with all history is presumably fairly large. That, coupled with your observation about different committer names makes me fairly worried that such an endeavour may be a timesink....

Tom

[adinn]

Tom Jenkinson wrote:

Thanks for the feedback. I am a bit concerned about how long a conversion might take as the transactions repo with all history is presumably fairly large. That, coupled with your observation about different committer names makes me fairly worried that such an endeavour may be a timesink....

Not really, you just set it running and leave it for a few hours to see if you have identified all named committers. Once you know all the name mappings are valid you can freeze the TS repo, run the convert for real, upload to git and unfreeze relative to the git master. It might take up to half a day to do the switcheroo but you should not have to freeze for more than that.

[dmlloyd]

Andrew Dinn wrote:

Tom Jenkinson wrote:

Thanks for the feedback. I am a bit concerned about how long a conversion might take as the transactions repo with all history is presumably fairly large. That, coupled with your observation about different committer names makes me fairly worried that such an endeavour may be a timesink....

Not really, you just set it running and leave it for a few hours to see if you have identified all named committers. Once you know all the name mappings are valid you can freeze the TS repo, run the convert for real, upload to git and unfreeze relative to the git master. It might take up to half a day to do the switcheroo but you should not have to freeze for more than that.

I agree with Andrew.  I've migrated a number of projects from SVN and it's really not too bad.  Furthermore, the svn-to-git import process is something which can be resumed at any time; I've used this technique to (manually) maintain git "mirrors" of external svn repositories (once you start using git, it can be really hard to go back to slow, slow svn).

In addition to arguments given above, I feel strongly that using git (espeically in conjunction with public services like github.com) makes it much easier for contributors to join projects and submit fixes.  It also makes it much less painful for contributors in the event that you reject a change; it is easier for them to fix, rebase, and resubmit a change under git than it is under SVN.

[marklittle]

I'd like to understand the pros and cons.

[tomjenkinson]

One major advantage seems to be the lightweight branching. Take this inflow work I am on with, to share this work with say David I can either check in to the 4.x branch or create a new branch to do the work till we are happy then merge my changes back in. Probably a similar process for both but swapping between branches is heavier on svn (from what I understand).

Take the scenario David is suggesting too. In this case he could have submitted a pull request to do the inflow for us and we could have worked through that way iteratively. I think it is possible to do some/all of this with svn but it seems much heavier.

Plus github is a fast server, my experience of svn.jboss.org has been it is slow, but maybe I just check out behemoth projects.

[marklittle]

Not convinced it's a problem for TS. It may look it for this one specific case, but I doubt it will be that useful in the long term. We discussed this several times within the team and didn't see a reason to move. I haven't seen or heard anything different recently.

[adinn]

Mark Little wrote:

Not convinced it's a problem for TS. It may look it for this one specific case, but I doubt it will be that useful in the long term. We discussed this several times within the team and didn't see a reason to move. I haven't seen or heard anything different recently.

I think this is avery bad decision. Tom did not sell git on its true merits. The most important benefit is that git really does make it much much easier for one person or several people to make parallel changes, For example  to do a long redesign of a moderate to large component of the code while still fixing small bugs. Even when the code is split into silos ownedby different devs that's a common scenario for a single indivdual. The great benefit si that it allows you to takedifferent changes and merge them in your own private branches to see hwo they mix without having to push them up the tree into a shared branch. That means you can try before you buy without having to have planned it in advance.

with svn you normally end up putting one set of changes into trunk  and then pulling it down into your branch only to find it breaks things too late. you can use svnto do collaborative work in branches but it requires you to plan all that collaboration in advance, merging changes into a shared branch before they can go into trunk. this also stops you  publishing to trunk until they are all done.

This is also very important for external collaborators. They cannot know what we are doing to the code so keeping their branch up to date as we makeincompatible changes forces them to continually import slabs of changes  into their edited repos in order to see if their patches still work. With git it is easy to check import the changes bit by bit and see where things break

[tomjenkinson]

Coindentally, I have just had two separate discussions with co-workers at the very same time regarding the performance of svn.jboss.org.

Does anyone know if it is "faster" (not just from a protocol point of view) to interact with github for a similarly sized project compared to one hosted on svn.jboss.org?

[adinn]

Tom Jenkinson wrote:

Does anyone know if it is "faster" (not just from a protocol point of view) to interact with github for a similarly sized project compared to one hosted on svn.jboss.org?

Yes, way faster. I know AS7 is a quite a bit smaller than AS6 but downlaoding AS6 from svn takes hours where downloading AS7 from github takes minutes.

[marklittle]

Understood, but like I said "not convinced". This is based on the amount of (or lack thereof) conflicts we've had over the years with concurrent activities. TS isn't as much in flux as other projects that we have, where I do see a good role for git. There are many other things that the team should be concentrating on with higher priority.

Now I could very well be wrong. But just looking at the svn trail over the past few months still reflects that svn is sufficient for us. And let's not forget that any "move to git" isn't really a move since we continue to use svn.

[adinn]

Mark Little wrote:

Now I could very well be wrong. But just looking at the svn trail over the past few months still reflects that svn is sufficient for us. And let's not forget that any "move to git" isn't really a move since we continue to use svn.

Err, no? I mean why? We were talking about moving the repo off svn onto git. Keeping ansvn repo around once the move was made would be pointless.