Move source repo to git

Couldn't the master repository be on Codehaus with a mirror for working on GitHub?

That is a possibility. What are the benefits for keeping the canonical source at codehaus?

One is quasi political – Codehaus supported Groovy, so it is good if Groovy-related project stay with Codehaus. Clearly GitHub is the place to hold the working master so people can clone and submit pull requests. Having the master master as a Codehaus project/repository makes it trivial to get artefacts into the Maven repository – something not entirely easy from GitHub. This last point is the second reason for staying at Codehaus.

First, groovy-eclipse does not produce maven artifacts. Well, groovy-eclipse-compiler and groovy-eclipse-batch are exceptions, but they are generated by a build process on my local machine and only done as needed.

I understand the political reason and I have indeed considered that, but so far, the infrastructure has not given me any particular confidence. For example, browsing via a webpage is currently disabled. Try to access any of the git urls in this page via a browser: http://docs.codehaus.org/display/GROOVY/Git

In theory I do want to support codehaus and leave the source code there, but there are no practical benefits for doing this. I'm willing for someone to convince me otherwise (so keep trying ) and I have talked to other members of the groovy team, but so far it does not seem like the right way to go.

Without artefacts to go into the Maven repository then the Codehaus repository holds little real appeal compared to housing the master at GitHub. Could always just house a mirror of the master at Codehaus for backup purposes?

A subversion-to-git migration will need a translation for the author formats. Subversion uses usernames (e.g. "danielphan") and git uses full names with email addresses (e.g. "Daniel Phan <d3phan@uwaterloo.ca>"). Here's the list of authors that github found when attempting to import a repository there:

• aclement
• werdna
• kdvolder
• nisingh
• surffan

I don't know if this list is complete.

I've also tried the import using the svn2git tool, but it seems it got stuck near the end. I'll log the output to a file this time to better diagnose what went wrong.

Hi Daniel,

the list of svn-users is complete. For fun I just did a migration of the svn (just trunk) to git. Resulting .git repo is 241M. It is so large because of the many (changing version of) libs/jars.
After that i did a

git log | grep Author: | sort | uniq

which resulted in:
Author: aclement <aclement@a5544e8c-8a19-0410-ba12-f9af4593a198>
Author: kdvolder <kdvolder@a5544e8c-8a19-0410-ba12-f9af4593a198>
Author: nisingh <nisingh@a5544e8c-8a19-0410-ba12-f9af4593a198>
Author: surffan <surffan@a5544e8c-8a19-0410-ba12-f9af4593a198>
Author: werdna <werdna@a5544e8c-8a19-0410-ba12-f9af4593a198>

The "strange" mail adresses were generated, cause I didn't have an authors translation file (Name + Email for each svn user).

I don't want to be smart-ass-ing here but maybe my tips are helpful: (Chances are high you know already all of that).

If you like you could go this route: In an empty folder

git svn init http://svn.codehaus.org/groovy/eclipse/trunk/
git svn fetch

after that you can add a remote and push all things you want there.
Also you can keep track of the svn until migration is all set by writing a cron job to keep up with trunk. Something like

git svn fetch
git merge git-svn
git push mainrepo master

Obviously you need to add that remote "mainrepo" before you can push.

Variations of the git svn init are to specify -t <tagfolder> and -T <trunk> separately and for sure -A authors.txt. In my experience svn-branches are usually less important ... but that is project-specific.

I guess you knew all or at least most of it ... but just for the case you didn't, i hope this can be helpful.

Cheers,
Kosta

Thanks Konstaninos. This is useful information.

We moved repos in mid-2009 and we lost the history before then. 80% of the codebase has been re-written, but we did lose some history. So, we should have more than those 5 committers, but unfortunately, the information is in a separate svn repository.

As for the size of the git repo, I do want to keep the full history available. So, I don't think there is much we can do about pruning the size or removing older jars.

I'll start looking into the git migration next week.

I have been trying to run svn2git, but to no avail. It seems to be failing on some non-existant tag that it can't find.

I am falling back on running git svn instead. We don't need to include the branches since they are for eclipse versions that are no longer supported and I can add the tags in manually later. So, if git svn works, I will go that way.

Experience of past conversions is that "git svn" always ended up being my route. The main loss was the lack of conversion of Subversion commiter identifiers to Git commiter identifiers. The major problem with the whole repository conversions is usually that the Subversion state is actually inconsistent. This invariably happens with Subversion repositories converted from CVS, but also when various svnadmin hacks have been applied with older versions of Subversion.

Given that you are not looking to preserve and entire correct history, I'd go now with "git svn"

"git svn" has always managed to correctly enter all branches and tags for me as long as you have a canonically structured Subversion repository or you give all the correct Git command line arguments to offer up the Subversion branch and tag directories as well as the trunk directory.

git svn has finished. It ran over night. The tags were not included, neither were the branches, but that's fine. Author tags were included.

Unfortunately, the size of the repo is almost 1G. I'm not sure if there is a way to keep the size down without losing significant history.

Now that I have this repo available, I can keep it up to date with git svn rebase.

Please don't publish a repository you are going to rebase: rebasing is fine for private repositories but really ###### off people who have forks.

I guess the bulk of the 1GB is actually all the jars that got stored?

The Groovy Subversion store is a bit of a mess so some problems are to be expected, but you should have been able to give branch and tag directories (if there are any) and have them turned into branches and tags in the Git repository. But if this doesn't matter to you then no problem.

Canonical location of git repository is here:

https://github.com/groovy/groovy-eclipse

I will also keep a mirror at codehaus.org.

Pushing is happening as I write this. Once complete, and all is OK, I will resolve this bug.

Complete.