GitHub migration procedure

Discussion about the project in general, organization, website, or any other details that aren't directly about the game.
Message
Author
User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: GitHub migration procedure

#166 Post by adrian_broher »

MatGB wrote:Most of this is way over my head, but for the release branch specifically there were three advantages, one was continued main trunk development, second being release branch specific changes (commenting out super Testers, changing default AI behaviour to beginner), the last allowing for a bugfix release for the current "stable" branch if we felt necessary.
You points are valid, but the last argument is a bit weak. There is no technical issues preventing one to branch of from a branch, tag or any commit in time. It would have been perfectly possible to create a new branch RELEASE_V_0_4_4_BUGFIX_1 from the RELEASE_V_0_4_4 tag in SVN or branching off a release-v0.4.4-bugfix.1 branch from the v0.4.4 tag or the corresponding commit hash/revision number starting a bugfix release from there.
Merging it back in is something I know not the pros and cons of, but I definitely don't want Test releases to not have Super Testers or have the default AI go back to Beginner.
I would prefer 'fixing' those by using command line parameters like every other game engine I know does this. Like Source or any Quake-ish Engine has as '--dev' or 'sv_cheats 1'.
Last edited by adrian_broher on Sat Mar 28, 2015 8:35 pm, edited 2 times in total.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

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

Re: GitHub migration procedure

#167 Post by Vezzra »

Dilvish wrote:If I'm understanding correctly (a nontrivial if), then it seems like Geoff and Vezzra don't have significant substantive concerns about Marcel's proposal specifically with regards to the 0.4.4 branch, but have been mostly wanting, more as a procedural matter...
As this merge Marcel proposes would be a real merge, that is, merge the changes that are now only present in the release branch actually back into master, my objection is more than a procedural matter, because I'd prefer to cherry pick things from the release branch back into master (if there actually is anything left that we might want to merge back), instead of having to undo changes to master we don't want there.

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

Re: GitHub migration procedure

#168 Post by Vezzra »

adrian_broher wrote:I generally have the feeling (and yes, it's mainly a gut feeling without any hard facts supporting it) that when we (or any other software development team) need release-specific changes we failed at some point in designing the application or build system properly.
adrian_broher wrote:I would prefer 'fixing' those by using command line parameters like every other game engine I know does this. Like Source or any Quake-ish Engine has as '--dev' or 'sv_cheats 1'.
You certainly have a point here, but that's something we can try to do better in future, it doesn't change the fact that the 0.4.4 release branch has some things in it we do not want to have merged back into master, while I can't think of anything (besides the changelog, which already got cherry picked) we might want to merge back. Hence my preference for not merging.
And the other commits are things, bug fixes and updated documentation, that should and must be shared between the main development branch and the release branch. So merging back release branches only seems a sensible choice to me.
Well, yeah, but shouldn't these things be committed to the main dev branch and then merged into the release branch in the first place? So the need to merge back anything from the release branch doesn't arise?

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

Re: GitHub migration procedure

#169 Post by adrian_broher »

Vezzra wrote:Well, yeah, but shouldn't these things be committed to the main dev branch and then merged into the release branch in the first place? So the need to merge back anything from the release branch doesn't arise?
I you actually meant cherry picking (merging includes the commit plus the diverted history and we don't want that on a release branch): yes, that's another way to approach the problem.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

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

Re: GitHub migration procedure

#170 Post by Vezzra »

adrian_broher wrote:I you actually meant cherry picking
Yes, of course, that's what I meant. A full merge of the main dev branch would kind of defeat the point of having a release branch ;)

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

Re: GitHub migration procedure

#171 Post by Vezzra »

After all this back and forth on the topic of merging release branches, do we have a definite decision now? Geoff expressed a preference for not merging, is that your final decision, Geoff? Or do you want to add anything? I want Marcel to be able to proceed ASAP, we've already spent a whole week with the migration. I don't consider that time wasted, given the results it was well worth it, but I also don't want to loose any more time...

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

Re: GitHub migration procedure

#172 Post by adrian_broher »

Vezzra wrote:After all this back and forth on the topic of merging release branches, do we have a definite decision now? Geoff expressed a preference for not merging, is that your final decision, Geoff? Or do you want to add anything? I want Marcel to be able to proceed ASAP, we've already spent a whole week with the migration. I don't consider that time wasted, given the results it was well worth it, but I also don't want to loose any more time...
Same here, the whole migration thing took a bit longer than expected. Sorry for that.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

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

Re: GitHub migration procedure

#173 Post by Vezzra »

adrian_broher wrote:Same here, the whole migration thing took a bit longer than expected. Sorry for that.
No need to apologize, the effort you put in to help us getting a cleaned up repo is very much appreciated. I think no one expects you to do that in record time on top of that. After all, you seem to have enough on your plate and squeezing that in as best as you can.

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

Re: GitHub migration procedure

#174 Post by Geoff the Medio »

From this discussion, I don't see any need or overwhelming preference for doing a merge now, so it seems reasonable to not do one.

Presumably, one can be done later if it is decided to do so, and there's no need to hold up other repository manipulations to wait for such a discussion.

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

Re: GitHub migration procedure

#175 Post by adrian_broher »

I'm currently uploading the repository to my github account and will move it to the freeorion org account as soon as I uploaded it.

Migration status (bold entries are new/updated to ):
* The whole repository now roots in the FreeOrion directory.
* The /trunk/FreeOrion/WindowsKit.zip (Windows SDK for version v0.1 and v0.2) was deleted from history.
* The /trunk/DesignerTools was split into a separate repository. I guess we can delete it.
* All authors were renamed to their name given on github, sourceforge and the credits file, prioritized as listed.
* All authors emails were fetched from github and the SVN repository UUID, prioritized as listed.
* All branches were retained, except of /branches/python-integration, which were never merged back to /trunk and is really old.
* All branches were renamed consistently lowercase, replacing underscores with dashes.
* Open branch endings and beginnings were stitched to their corresponding split/merge commit, except /branches/release-0.4.4 as this branch was and should never be merged back to /trunk.
* All tags were retained and converted to annotated tags, except of /tags/RELEASE_V_0_1_INSTALLER, /tags/RELEASE_V_0_2_INSTALLER and /tags/start
* All version tags were renamed to match semantic version tagging vMAJOR.MINOR.PATCH
* All missing tags from http://www.freeorion.org/index.php/Compile#Tarballs were added with Geoff as tagger, copying the commit date and the commit message to commit tagged.
* Enforced LF line endings for whole commit history.
* Added .gitattributes to apply proper native line endings when checking code out, normalizing text files to LF when checking in. Adding special cases for VS and Xcode specific files. Excluded binary files from line ending normalization.
* Applied most recent commits from freeorion:freeorion repository master branch with proper author, time and committer (No time traveling for you, included all commits up to 1eb882861caccc9c39e78655976a6737b910baf2).
* Added logging-migration branch from freeorion:freeorion-fixed to the new repository with proper author, time and committer.
* Unstitched release-v0.4.4 branch.
* Repacked the whole repository from 853Mb to 468Mb.


Time for the loose ends:

I suggest to:
* Delete all merged branches to remove clutter. So every branch except: master, release-v0.4.4 and logging-migration.
* Delete the release-v0.4.4 branch. The release has already a tag, which keeps the history alive and we don't work on a bugfix release for v0.4.4 so no branch is required here IMO.
* Delete the v0.4.4-rc* tags. Tags do mainly map to releases on github. I don't think that end users are really interested into our internal testing release candidates.

Other things to consider:

If or how we migrate the open tickets and feature requests from sourceforge to github.
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: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: GitHub migration procedure

#176 Post by Geoff the Medio »

adrian_broher wrote:* Enforced LF line endings for whole commit history.
Except for VS/XCode files, presumably? Might lead to some commits with no changes, or commits with some files marked as modified by not actually changed. (Which I assume is not really a problem...)
* Delete the release-v0.4.4 branch. The release has already a tag, which keeps the history alive and we don't work on a bugfix release for v0.4.4 so no branch is required here IMO.
How do we point people to a particular commit for building the release then, when the release has changes not present in master? What does having a tag mean if the branch containing the commit that was tagged is deleted...?

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

Re: GitHub migration procedure

#177 Post by adrian_broher »

Geoff the Medio wrote:Except for VS/XCode files, presumably?
No, this includes this files too. They are converted when checking out the file according to the rules given in the .gitattributes file, which I mentioned in a previous post.
The rules are something like:
All text files: Check those out with the native line ending of the platform.
Except VS project files: Check those out with CRLF regardless of platform.
Except Xcode project files: Check those out with LF regardless of platform.
Except binary files: leave them as is.
Geoff the Medio wrote:Might lead to some commits with no changes, or commits with some files marked as modified by not actually changed. (Which I assume is not really a problem...)
That's right, but you can tell git to skip those noop commits when rewriting history (which is what we did when removing any end-of-line inconsistencies). That's why there are 8051 commits in the SVN history and 7828 commits in the git history, the splitting out of DesignTools, the deletion CVSROOT folder, the removal of the WindowsKit.zip and the line ending fights/fixes commits add up to those missing 223 commits.
Geoff the Medio wrote:How do we point people to a particular commit for building the release then, when the release has changes not present in master?
We point them to the tag, that was added for the commit. Tags are named commits. Github even provides direct urls to tags like for example: https://github.com/freeorion/freeorion/ ... tag/v0.4.4
Geoff the Medio wrote:What does having a tag mean if the branch containing the commit that was tagged is deleted...?
I don't understand your question, sorry.
Last edited by adrian_broher on Sun Mar 29, 2015 10:51 am, edited 1 time in total.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

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

Re: GitHub migration procedure

#178 Post by adrian_broher »

I just moved the uploaded repository into the freeorion account, renaming freeorion:freeorion to freeorion-backup3.

I consider the migration of the repository therefore done.

Time to get your new fresh copy of the code.
Last edited by adrian_broher on Sun Mar 29, 2015 12:13 pm, edited 1 time in total.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

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

Re: GitHub migration procedure

#179 Post by Vezzra »

adrian_broher wrote:I consider the migration of the repository therefor done.
Time to celebrate :D

So, I assume that means we do not have to check or verify things before we finally proclaim recommencement of normal operation. Good. Well, things have been checked and re-checked thoroughly at this point.

The git era finally has begun! 8)

User avatar
MatGB
Creative Contributor
Posts: 3310
Joined: Fri Jun 28, 2013 11:45 pm

Re: GitHub migration procedure

#180 Post by MatGB »

And now all you have to do is explain what us poor plebs have to do ;-)

(from what's been said, I'll not bother with TortoiseGit and instead try one of the other options, this might be fun...)
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

Post Reply