GitHub migration procedure
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: GitHub migration procedure
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?
For the repository re-importing, can you make the new one to test without deleting the old?
Re: GitHub migration procedure
Ok.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.
Sure. I'll rename the old one to "fo-backup" or something like that, then import the SVN repo again as "freeorion".For the repository re-importing, can you make the new one to test without deleting the old?
But I was going to do at least another test import before doing the real thing anyway.
Re: GitHub migration procedure
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.adrian_broher wrote:Is there anything else you need?
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: GitHub migration procedure
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: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.
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
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: GitHub migration procedure
I would like to transfer ownership, but I can't because I don't have administrator rights on the freeorion org account.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.
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
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: GitHub migration procedure
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...
Re: GitHub migration procedure
Please add notification to this thread about changes: viewtopic.php?f=12&t=9357 Something like: migration in progress dont fork.Vezzra wrote:Sure. I'll rename the old one to "fo-backup" or something like that, then import the SVN repo again as "freeorion".
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
Re: GitHub migration procedure
As suggested by githib help, you are now a member of the Assets team, which has admin rights to its (currently nonexistent) repos.adrian_broher wrote:I would like to transfer ownership, but I can't because I don't have administrator rights on the freeorion org account.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.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: GitHub migration procedure
I transferred the repository as requested.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.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Re: GitHub migration procedure
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?Cjkjvfnby wrote:Code: Select all
git checkout release-0.4.4 git cherry-pick a98d107199614b64971c11d1c566d0ad44f1c9b4 git push
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: GitHub migration procedure
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?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...
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.
Re: GitHub migration procedure
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.Cjkjvfnby wrote:Please add notification to this thread about changes: viewtopic.php?f=12&t=9357 Something like: migration in progress dont fork.
In addition to that I can make another post immediately before I start the reimport of course.
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.PS. Looks like my post was missed:
viewtopic.php?p=75674#p75674
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: GitHub migration procedure
No.Vezzra wrote:Is the old "DesignerTool" directory the only other top level folder that has ever existed besides "FreeOrion"...
In that case, unless adrian_broher has a simple solution, import the actual root which contains FreeOrion/...one serious issue remains...
Re: GitHub migration procedure
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.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 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).
Re: GitHub migration procedure
I will check it when back home and report.Vezzra wrote:They have all been merged back into trunk
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