GitHub migration procedure

Discussion about the project in general, organization, website, or any other details that aren't directly about the game.
Post Reply
Message
Author
User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12290
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: GitHub migration procedure

#61 Post by Geoff the Medio » Tue Mar 24, 2015 12:41 am

I prefer to keep the FreeOrion directory at the root of the tree, as it supports the current structure of the Windows SDK in which the libraries and headers of dependencies are in separate directories from the FreeOrion code.

For the repository re-importing, can you make the new one to test without deleting the old?

User avatar
Vezzra
Release Manager, Design
Posts: 4686
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: GitHub migration procedure

#62 Post by Vezzra » Tue Mar 24, 2015 5:40 am

Geoff the Medio wrote:I prefer to keep the FreeOrion directory at the root of the tree, as it supports the current structure of the Windows SDK in which the libraries and headers of dependencies are in separate directories from the FreeOrion code.
Ok.
For the repository re-importing, can you make the new one to test without deleting the old?
Sure. I'll rename the old one to "fo-backup" or something like that, then import the SVN repo again as "freeorion".

But I was going to do at least another test import before doing the real thing anyway.

User avatar
Vezzra
Release Manager, Design
Posts: 4686
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: GitHub migration procedure

#63 Post by Vezzra » Tue Mar 24, 2015 5:46 am

adrian_broher wrote:Is there anything else you need?
Something came to mind: You've set up a "freeorion-assets" repo in your personal account. Can you move it to the freeorion organizational account? We can of course also just fork it, if you prefer that.

User avatar
adrian_broher
Programmer
Posts: 1072
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: GitHub migration procedure

#64 Post by adrian_broher » Tue Mar 24, 2015 7:03 am

Geoff the Medio wrote:I prefer to keep the FreeOrion directory at the root of the tree, as it supports the current structure of the Windows SDK in which the libraries and headers of dependencies are in separate directories from the FreeOrion code.
That is one of the reasons why I proposed that the FreeOrion directory should go away. With the current layout the SDK directory needs to be placed within the repository and contributors may unintentionally commit parts of the SDK into the repository. Take for example the Windows SDK as referred by current master/HEAD:


Repository starts at /
/
/FreeOrion
/FreeOrion/msvc2010/FreeOrion/FreeOrion.vcxproj < starting point for resolving libraries and header include directories.
/include < as referenced by AdditionalIncludeDirectories: ../../../include/ ; is located within the repository
/Boost/include/ < as referenced by AdditionalIncludeDirectories: ../../../Boost/include/ ; is located within the repository
/lib < as referenced by AdditionalLibraryDirectories: ../../../lib/ ; is located within the repository
/Boost/lib < as referenced by AdditionalLibraryDirectories: ../../../Boost/lib/ ; is located within the repository

So the .gitignore must contain at least:
/lib/
/Boost/

And there is still some risk of unintentionally committing stuff that doesn't belong into the repository whenever someone derives from adding dependencies from a different directory than /lib/;/include/;/Boost/. Placing the SDK outside of the repository this cannot happen and there is no need to change the SDK at all for this (I used the repository that way for all platforms with unmodified SDKs and didn't have any problems). For comparison

Repository starts at /freeorion.git
/
/freeorion.git
/FreeOrion/msvc2010/FreeOrion/FreeOrion.vcxproj < starting point for resolving libraries and header include directories.
/include < as referenced by AdditionalIncludeDirectories: ../../../include/ ; is located outside of the repository
/Boost/include/ < as referenced by AdditionalIncludeDirectories: ../../../Boost/include/ ; is located outside of the repository
/lib < as referenced by AdditionalLibraryDirectories: ../../../lib/ ; is located outside of the repository
/Boost/lib < as referenced by AdditionalLibraryDirectories: ../../../Boost/lib/ ; is located outside of the repository
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
adrian_broher
Programmer
Posts: 1072
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: GitHub migration procedure

#65 Post by adrian_broher » Tue Mar 24, 2015 7:07 am

Vezzra wrote:Something came to mind: You've set up a "freeorion-assets" repo in your personal account. Can you move it to the freeorion organizational account? We can of course also just fork it, if you prefer that.
I would like to transfer ownership, but I can't because I don't have administrator rights on the freeorion org account.
Transfer ownership
Transfer
Transfer this repo to another user or to an organization where you have admin rights.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12290
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: GitHub migration procedure

#66 Post by Geoff the Medio » Tue Mar 24, 2015 7:39 am

I don't think it's likely people will commit parts of the repository, but I don't care if (what will be for me) the FreeOrion (which contains the root CMakeLists.txt and all the code directories like universe and util) directory is the root, or one subdirectory within the the root of the repository, so that can change if you want. I'm not concerned about the old DesignerTool history being present (or not) in the git repository history, as long as the main FreeOrion programs' code and assets are present...

User avatar
Cjkjvfnby
AI Contributor
Posts: 452
Joined: Tue Jun 24, 2014 9:55 pm

Re: GitHub migration procedure

#67 Post by Cjkjvfnby » Tue Mar 24, 2015 8:18 am

Vezzra wrote:Sure. I'll rename the old one to "fo-backup" or something like that, then import the SVN repo again as "freeorion".
Please add notification to this thread about changes: viewtopic.php?f=12&t=9357 Something like: migration in progress dont fork.

PS. Looks like my post was missed:
viewtopic.php?p=75674#p75674
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Dilvish
AI Lead, Programmer
Posts: 4736
Joined: Sat Sep 22, 2012 6:25 pm

Re: GitHub migration procedure

#68 Post by Dilvish » Tue Mar 24, 2015 8:29 am

adrian_broher wrote:
Vezzra wrote:Something came to mind: You've set up a "freeorion-assets" repo in your personal account. Can you move it to the freeorion organizational account? We can of course also just fork it, if you prefer that.
I would like to transfer ownership, but I can't because I don't have administrator rights on the freeorion org account.
As suggested by githib help, you are now a member of the Assets team, which has admin rights to its (currently nonexistent) repos.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
adrian_broher
Programmer
Posts: 1072
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: GitHub migration procedure

#69 Post by adrian_broher » Tue Mar 24, 2015 8:35 am

Dilvish wrote:As suggested by githib help, you are now a member of the Assets team, which has admin rights to its (currently nonexistent) repos.
I transferred the repository as requested.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Dilvish
AI Lead, Programmer
Posts: 4736
Joined: Sat Sep 22, 2012 6:25 pm

Re: GitHub migration procedure

#70 Post by Dilvish » Tue Mar 24, 2015 8:46 am

Cjkjvfnby wrote:

Code: Select all

git checkout release-0.4.4
git cherry-pick a98d107199614b64971c11d1c566d0ad44f1c9b4
git push
Reading up a bit on git cherry-pick, it looks to me like we'd probably want to also use the -x option in the cherrypick line. But I'll confess, I still haven't figured out just what the purpose of this particular cherrypicking is; could you explain it to me?
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Vezzra
Release Manager, Design
Posts: 4686
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: GitHub migration procedure

#71 Post by Vezzra » Tue Mar 24, 2015 9:11 am

Geoff the Medio wrote:I'm not concerned about the old DesignerTool history being present (or not) in the git repository history, as long as the main FreeOrion programs' code and assets are present...
Is the old "DesignerTool" directory the only other top level folder that has ever existed besides "FreeOrion", or have there been others that come to your mind we might want to keep?

Regardless, one serious issue remains when trying to get rid of the top level "FreeOrion" directory by means of importing only the tree below "FreeOrion": the entire branches and tags history will not be imported in the new repo, as our SVN repo has the standard trunk/branches/tags setup, with "FreeOrion" contained in trunk. If the setup had "FreeOrion" and "DesignerTools" at the root level, and a separate trunk/branches/tags structure within each of the top level directories, we could import just "FreeOrion", but alas...

Assuming that you want to preserve not only the commit history of trunk, but also of the branches and tags, we can't eleminate the top level "FreeOrion" dir when doing the import. This has to be an extra step afterwards. Once again, as project lead this decision is yours. Tell me what you want, and I will do the reimport accordingly.

User avatar
Vezzra
Release Manager, Design
Posts: 4686
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: GitHub migration procedure

#72 Post by Vezzra » Tue Mar 24, 2015 9:18 am

Cjkjvfnby wrote:Please add notification to this thread about changes: viewtopic.php?f=12&t=9357 Something like: migration in progress dont fork.
I already intend to post another message in that thread announcing that we have to redo the import very soon, and people should refrain from forking/cloning/committing work to the repo unless that's done. And informing those that already did fork/clone it that they will have to do that again.

In addition to that I can make another post immediately before I start the reimport of course.
PS. Looks like my post was missed:
viewtopic.php?p=75674#p75674
Sorry, I didn't miss it, I plan to get back to this post once the reimport is done. Is that ok? After you've been added as contributer, do you still get the 404 error? There isn't much I can do about it other than removing the link.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12290
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: GitHub migration procedure

#73 Post by Geoff the Medio » Tue Mar 24, 2015 9:23 am

Vezzra wrote:Is the old "DesignerTool" directory the only other top level folder that has ever existed besides "FreeOrion"...
No.
...one serious issue remains...
In that case, unless adrian_broher has a simple solution, import the actual root which contains FreeOrion/

User avatar
Vezzra
Release Manager, Design
Posts: 4686
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: GitHub migration procedure

#74 Post by Vezzra » Tue Mar 24, 2015 9:28 am

Dilvish wrote:But I'll confess, I still haven't figured out just what the purpose of this particular cherrypicking is; could you explain it to me?
The problem is the .gitignore file has only been added to trunk. If someone checks out one of the branches, he won't get the .gitignore, which is obviously a bad thing.

The question is, which branches we intend to keep anyway. They have all been merged back into trunk, and I don't think it would be a particularly brilliant idea to continue working with a branch that was originally created in the SVN repo. I suspect git will have troubles handle merging of a svn branch cleanly.

Instead we should remove the branches after the import (no need to hurry, but eventually). This will only remove the markers that point to the last commit of these branches, their commit history will be left intact (which is what we want).

User avatar
Cjkjvfnby
AI Contributor
Posts: 452
Joined: Tue Jun 24, 2014 9:55 pm

Re: GitHub migration procedure

#75 Post by Cjkjvfnby » Tue Mar 24, 2015 10:15 am

Vezzra wrote:They have all been merged back into trunk
I will check it when back home and report.

upd. I missed that it is not git. Merging this branches to master gives me huge diff. So I can't figure out if any useful code in this branches.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Post Reply