Git Migration

[ShivaFang]

GitLab is super super slow. It's taking a few minutes minutes for each page request (when I don't get a 502 error) and I've been waiting half an hour for a confirmation email.

Is this typical?

EDIT: Okay whatever the issue was it seems to have passed and is working fast now.
EDIT2: *sigh* it's back to timing out while I'm trying to fork the repository. Whatever the problem is it's intermittent. It's not affecting any other site I'm using so it must be on GitLab's end.

[ShivaFang]

As long as your changes are in your local repository (i.e. committed, pushed does not matter), git will help you merge the files. That only deltas are transferred should be of no concern for your workflow.

What command do I have to use to merge the trunk (or master branch I think git calls it) to my local repository if I've made changes? Surely I don't re-clone it each time.
EDIT: Nevermind... I used git once before.. it's a 'pull' request, right?

Edit2:
Okay seems you were right - I got it all cloned and I did a quick test and it looks like on IntelliJ I just go VCN/Update (same as I would do before) so it seems exactly 100% the same.

[ShivaFang]

Oops.. I tried to run it after cloning it. Is it missing a few packages?
I'm getting errors for the following;
com.google.common
com.apache.common

EDIT: Poking around on my own using my limited knowledge and comparing it to the old project - all of these files have the word 'Maven' next to them. I vaguely recall setting up some kind of maven dependencies when I set this up the first time. friarsol may want to add that to his instructions.

If anyone else comes across this in IntelliJ - the soloution is the click on the sideways "Maven Project" button on the rightand then there's a button with two arrows going in a circle - that will install the dependancy files.

I'm now getting this error that is not anything I have any idea about;
"Error:java: Annotation processing is not supported for module cycles. Please ensure that all modules from cycle [test1,main4,main3,main1,main2,forge-gui-mobile] are excluded from annotation processing"

(4:37)
Okay.. so the issue there is a setting that Maven did when importing stuff. Going to Settings/Compiler/Annotation Processors and clicking 'Maven default annotation processors' and disabling it got me past that error.

I'm now getting a message saying that android SDK is not set... I'm not sure why I need android SDK when I've got my project configured for desktop (I used the same configuration as the svn project)... but I happen to have the android SDK installed since I needed it for an app I built for a client. I'm a little worried I've got something skrewed up in my project settings... but so far I'm doing this one error at a time.

(4:49)
Odd.. I added the Android SDK to the project settings (Ctrl-Alt-Shift-S) and I'm still getting the same message;
Error:Android Pre Dex: [forge-gui-android] Android SDK is not specified

(4:55)
Okay - I decided to delete the Android directory and hope I don't screw anything up. In IntelliJ hitting the 'delete' key removes it from the project without deleting it (whew) and now it runs! Hurray!

Now to work on adding all my hacks to the project to set it up the way it was before - but that's all me.. stuff that I probably won't be able to get help with. I did it all once before I'm sure I can do it again.

[friarsol]

Now to work on adding all my hacks to the project to set it up the way it was before - but that's all me.. stuff that I probably won't be able to get help with. I did it all once before I'm sure I can do it again.

I would recommend the same thing I did to Seravy. Create a git aware svn patch (if you still have the svn forge folder), then apply that on the git side. Or of course you can just copy paste the files over and see how well that works.

[ShivaFang]

Now to work on adding all my hacks to the project to set it up the way it was before - but that's all me.. stuff that I probably won't be able to get help with. I did it all once before I'm sure I can do it again.

I would recommend the same thing I did to Seravy. Create a git aware svn patch (if you still have the svn forge folder), then apply that on the git side. Or of course you can just copy paste the files over and see how well that works.

I saw that (and I stumbled on how to do it when I was checking all my changes before I started the conversion) - but I have so few changes to actual files - most of it is files I created (that I can just stick in the right folder). I have maybe 5 files that I need to add 1 line to each, so it's just as easy to do by hand, really. (Most of it is just checking for nulls in a few weird places because I bypass some of the checks that happen when setting up games so there are nulls where there wouldn't be in normal day-to-day operations.. and then the line of code that launches my simulation from the lobby.)

(an hour later)
EDIT: Hurray! I got it all working. I was really anxious when I saw that git migration was in progress. It was relatively painless overall.

[friarsol]

EDIT: Hurray! I got it all working. I was really anxious when I saw that git migration was in progress. It was relatively painless overall.

Yea it's going to mean different things to different people. But there's already a few devs working on the project who weren't just a week ago, so I think that's a big gain. Fixing small copy issues are going to be more annoying, but everything should at least have a second pair of eyes, so that should overall be a positive too. Hopefully in a few months (after all the snapshot releases are back up to regular time), noone will even remember we migrated over.

[ShivaFang]

EDIT: Hurray! I got it all working. I was really anxious when I saw that git migration was in progress. It was relatively painless overall.

Yea it's going to mean different things to different people. But there's already a few devs working on the project who weren't just a week ago, so I think that's a big gain. Fixing small copy issues are going to be more annoying, but everything should at least have a second pair of eyes, so that should overall be a positive too. Hopefully in a few months (after all the snapshot releases are back up to regular time), noone will even remember we migrated over.

What's funny is that when I first started doing this (right after KLD IIRC) is that I had some familiarity with git and 0 knowledge of svn. I had used a little git a few years ago when I was doing ludum dare with a parner (I usually only code on my own, so I didn't know anything about version control since I didn't need to share my work) so I would have been less intimidated with git than svn. However finding out that this was migrating to git when I already had it all working was a bit of a stress trigger. It's odd how perspectives change.

I'll know when the first changes happen how successful this was - but from what I can see right now it is 100% the same as it was before, now that I have it all set up.

[ShivaFang]

hm.. a question if you don't mind...

when I go to VCS/Update it gives me the option to Merge/Rebase/Branch Default and Using Stash/Using Shelve. I know I don't want to Merge - since the main source doesn't need what I'm doing. I'm not entirely sure what Branch Default does. From everything I've read on Rebasing... that sounds like what I want to do, right? IntelliJ defaults to Branch Default and Using Stash.

I have a gut feeling that 'Branch Default' just checks for updates to the fork I made - which isn't something I'm updating (or maybe I am when I commit.. IDK). I basically want to do what I did on svn where I was basically updating from the trunk without changing the trunk. IE - I want all the RIX cards and supporting code when that starts.

[silly freak]

If you kept a patch with SVN, I think this is more like rebase, but I can't say for sure.

Branch default is just merge or rebase as configured on a per-branch basis.

I'm starting to think about collecting/writing some git documentation in the wiki, but I'm only comfortable covering my tool of choice, smartgit, as well as tool-independent git stuff. Would that be appreciated?

[ShivaFang]

If you kept a patch with SVN, I think this is more like rebase, but I can't say for sure.

No, I didn't use a patch. I just modified the files. Whenever I updated it would inform me of merge conflicts, which I looked through and made adjustments as necessary.

Anyway from what you said to me, it sounds like rebase is the option I want (which is sort of what I was thinking anyway - but often my instincts on these things are wrong when I don't know to the tools well.)

[silly freak]

(if anyone's interested: https://www.slightlymagic.net/wiki/Git_Introduction)

[Seravy]

"3. Recreate your patch so that it's compatible with git (svn diff --git >> gitFormat.patch)"

I'm getting "invalid option --git" for this. It seems I need a newer SVN for this, I'll try to install one and see what happens..."requires windows vista or later", well so much for that. Anyone can point me to an SVN that has this --git option and works on XP?

[silly freak]

When you have the patch applied, you can also try to just copy the files over to your clone. Git will detect the changes and you can go from there.

(BTW, having an XP system connected to the internet is risky...)

[Seravy]

The SVN workspace is like 3 months old and I get server errors if I try to update it.

Or am I supposed to copy the files from the Git folder into the SVN first then apply patches and put them back? I guess it's worth a try... oh yeah this has like a million files, this will take a while.

[silly freak]

I'd suggest the other way round. What commit do you have in the SVN? Look for that commit in Gitlab, check it out in your clone, then copy the locally changed files from SVN to git, that should give you a consistent compilable state. Then work from there. I can try to assist you.