Git for real this time.

billw2015

King
Joined
Jun 22, 2015
Messages
837
UPDATE:
This information is out of date please see https://forums.civfanatics.com/threads/git-is-ready.649070/ for updated information.



The language with which people are discussing moving to git for development appears to now be in terms of "when", not "if", so I want to nail down specifics now.

Are we decided to use SVN for alpha/beta releases going forward?
This would mean we would periodically (either manually or automatically, or a combination) push builds to SVN consisting only of the release parts of the mod, no source or loose art assets. It would be like a the contents of a release, but in SVN. I think it is a good idea, players don't need to change anything at all.

Has anyone who isn't sure about this taken the small amount of time necessary to familiarize themselves with how to use git via one of the existing UI clients?
I made a video of setup from start to finish here for one of them (please make sure closed captions are enabled, although they should be by default). It takes 5 minutes and is hopefully pretty clear. If you want something like TortoiseSVN you could use TortoiseGit, but I think it is more complicated than what I present in that video.
If there is anything in there you don't understand or want help with, or you want want to use another client and want help with that then please reply here or start a thread! If you want more "live" help then discord might be a good place to ask. If it is for how to setup using a specific client then I can make a video showing how (I could do this for TortoiseGit for instance if people want to use it).

I will add more questions here when I think of them...

/edit
If you want to get a head start then sign up on github.com.

/edit 2
The video I linked above still points to the experimental repository, I will update it to point at the new one when it is ready.
 
Last edited:
Update on that video that would make things even simpler is to not bother switching to the main-dev stream or whatever I called it. Instead do main dev in master, and have a separate stable branch for changes to go to SVN. Workflow is essentially a 1:1 mirror of SVN workflow for most people then. Except way faster.
 
I don't think so.

I created a merge request for Initial setup and started to add files.
A few things must be still worked out like how to replace the version.h generation.
 
Yeah WRT to version.h I can do something, but of course there is no such thing as *next* revision number in git. I will have a look at source indexing for git (I only did it with Perforce before), and then we can have appveyor make our dll builds, embed source indexing information for us along with git hash. On that note I sent an invite to c2c on github to install appveyor. Once done I can add the github team to appveyor team, and proceed from there.
 
@billw2015
So far everything seems to be working you could try out the Initial-Setup branch and comment here or on GitHub if you find problems.

I changed some of your scripts a bit to get C2C running from git!
These steps are necessary to setup C2C.
  • Use the Install.bat
  • Use the PackFPKs.bat
  • And compile the dll
 
Funny I literally just yesterday read the counter point to that article: https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/

However I think most devs don't need to worry about either of these. I would suggest most devs work in master, and we can branch for features when we need to. It is not what I normally do but I think it better matches how this mod has been developed up until now. We then have a release branch (which I saw you added already) which we can merge to for automatic deployment to SVN.
 
We have a TO-DO list here, not all of it needs to be done, but definitely need to get FPK Live working for anyone who doesn't want to have to run the batch file to build the FPKs (or forgets to), and I want to get the pipeline for automating builds back to SVN in place as well.
 
@billw2015
I'am thinking about the branch names.

How about using a release branch for releases including betas and preview. These could be deployed to svn.

Instead calling the development branch master i would call it develop. That would make it easier for people who never used git to identify the purpose of these branches.
 
I think yes for release branch, it was already my plan to automate deployment of any commits in that stream to SVN and maybe github release.
Not sure what you are saying exactly about develop branch, you mean rename master to develop, or have separate develop branch?
 
Top Bottom