Details

    • Number of attachments :
      0

      Description

      We will be moving the Groovy-Eclipse source repository to git. Likely, the canonical repository will be located at github.

        Activity

        Hide
        Russel Winder added a comment -

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

        Show
        Russel Winder added a comment - Couldn't the master repository be on Codehaus with a mirror for working on GitHub?
        Hide
        Andrew Eisenberg added a comment -

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

        Show
        Andrew Eisenberg added a comment - That is a possibility. What are the benefits for keeping the canonical source at codehaus?
        Hide
        Russel Winder added a comment -

        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.

        Show
        Russel Winder added a comment - 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.
        Hide
        Andrew Eisenberg added a comment -

        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.

        Show
        Andrew Eisenberg added a comment - 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.
        Hide
        Russel Winder added a comment -

        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?

        Show
        Russel Winder added a comment - 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?
        Hide
        Daniel Phan added a comment - - edited

        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.

        Show
        Daniel Phan added a comment - - edited 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.
        Hide
        Konstantinos Kostarellis added a comment -

        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

        Show
        Konstantinos Kostarellis added a comment - 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
        Hide
        Daniel Phan added a comment -

        Thanks for this, I'm neither a git nor an svn expert so all information is helpful.

        Show
        Daniel Phan added a comment - Thanks for this, I'm neither a git nor an svn expert so all information is helpful.
        Hide
        Andrew Eisenberg added a comment -

        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.

        Show
        Andrew Eisenberg added a comment - 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.
        Hide
        Andrew Eisenberg added a comment -

        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.

        Show
        Andrew Eisenberg added a comment - 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.
        Hide
        Russel Winder added a comment -

        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.

        Show
        Russel Winder added a comment - 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.
        Hide
        Andrew Eisenberg added a comment -

        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.

        Show
        Andrew Eisenberg added a comment - 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 .
        Hide
        Russel Winder added a comment -

        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.

        Show
        Russel Winder added a comment - 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.
        Hide
        Andrew Eisenberg added a comment -

        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.

        Show
        Andrew Eisenberg added a comment - 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.
        Hide
        Andrew Eisenberg added a comment -

        Complete.

        Show
        Andrew Eisenberg added a comment - Complete.

          People

          • Assignee:
            Andrew Eisenberg
            Reporter:
            Andrew Eisenberg
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: