Author Topic: Policy regarding git branching and Visual Studio project upgrade  (Read 270 times)  Share 

Monsieur OUXX

  • Cavefish
  • Mittens Vassal
  • Mittens Half Initiate
    • I can help with proof reading
    •  
    • I can help with translating
    •  
    • I can help with voice acting
    •  
It's just a question :
-If I branch away from the project and open it with a Visual Studio version more recent than the files in the repository, ...
... i'll have to commit all my changes, including the automated update to the solution and project files (.sln, .csproj...) made by visual Studio at the time I opened them.

Should I commit that? If not, how should I handle it?
 

Crimson Wizard

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
If you intend to later merge particular branch back to the central repository, you need always to keep in mind what changes you bring with it. You may already know that such merge is done using "pull request", which is that you suggest certain branch from your repository to be merged into central one. With that, every single commit done to that branch will be included.

Pull request policy, as well as commit recommendations are described here:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=50001.0
and here:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=50001.msg636481384#msg636481384


With Git there is always a way to copy commits from branch to branch, and even pick out particular modifications. This opens an opportunity to work in two stages: first have a "dirty" branch, where you experiment, and then create a "clean" branch, and copy only changes you mean to merge. If you were splitting changes by kind and commit them separately (e.g. one commit for solution/project update, second commit for changes in actual code), this migration can be done with much less effort.

Of course all this assumes that changing to different MSVS won't require changing the code too in some way...  Then following actions depend on the nature of these changes, and whether central repository got updated to same version while you were working on your branch.



Additionally, there is an option to keep separate solutions for every supported MSVS. That may be ok for projects that rarely change project contents (e.g. add more files). But with AGS there is always a chance large piece of code gets refactored and splitted into several code files. When this happens, every project will need to be updated, which is a chore to remember (and easy to miss). Since the actual number of project maintainers is... well, currently 1,... adding extra organizational issue seem to be a very bad idea.
« Last Edit: 16 Mar 2017, 18:42 by Crimson Wizard »

Monsieur OUXX

  • Cavefish
  • Mittens Vassal
  • Mittens Half Initiate
    • I can help with proof reading
    •  
    • I can help with translating
    •  
    • I can help with voice acting
    •  
If you were splitting changes by kind and commit them separately (e.g. one commit for solution/project update, second commit for changes in actual code), this migration can be done with much less effort.
That's what I did, but I don't see how it causes less efforts, as git has a tendency to make you merge the whole branch history (i.e. the complete list of commits), without letting you choose which inner commits to push. But I don't know git well, so I probably have no idea of what I'm talking about.
I suppose we can see at merge time; my changes would maybe add new files in the project, but the XML of the .csproj files is easy to understand at merge time (to sort the important structural changes to the file from the "version-related" ones)
 

Crimson Wizard

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
If you were splitting changes by kind and commit them separately (e.g. one commit for solution/project update, second commit for changes in actual code), this migration can be done with much less effort.
That's what I did, but I don't see how it causes less efforts, as git has a tendency to make you merge the whole branch history (i.e. the complete list of commits), without letting you choose which inner commits to push.

I was referring to first doing work in a "dirty" branch and then copying commits to the "clean" branch, both branches being in your repository. This is done using special git command called "cherry pick", which I find extremely useful at times (but that may be subjective and related to how person works with git).
I sometimes do that when I am not certain about final outcome. In the end, only "clean" branch is merged, and dirty one either deleted, or saved for the future "picking out", if something useful but unused remained there.

Monsieur OUXX

  • Cavefish
  • Mittens Vassal
  • Mittens Half Initiate
    • I can help with proof reading
    •  
    • I can help with translating
    •  
    • I can help with voice acting
    •  
Oh, OK, I didn't get it. That's clever. Yeah I'll do that.

By the way at the moment which Visual Studio version is it? Maybe I have it (I'm toying in a professional environment where I have many machines with lots of software installed).

Off-topic : I remember a project using a tool called CMake which can be rather simply used (through a rather simple script language) to generate projects for any IDE or compiler. You feed it the .cs and all, and it gives you the .sln and .csproj, for any verison of Visual Studio (or even other editors) you wish.

« Last Edit: 17 Mar 2017, 09:34 by Monsieur OUXX »
 

Crimson Wizard

  • Local Moderator
  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
By the way at the moment which Visual Studio version is it? Maybe I have it (I'm toying in a professional environment where I have many machines with lots of software installed).

Right now it is MSVS 2008 SP1, but I just removed all restrictions in the master branch (precompiled libs), so you can use any.
I was thinking about upgrading to MSVS 2015 Community Edition.

Off-topic : I remember a project using a tool called CMake which can be rather simply used (through a rather simple script language) to generate projects for any IDE or compiler. You feed it the .cs and all, and it gives you the .sln and .csproj, for any verison of Visual Studio (or even other editors) you wish.
Actually that may be a good idea to include these. I never created CMake scripts from scratch though, only edited some.

What should be kept in mind: MSVS you use define which VC redistributable packages has to be installed on users PC for running AGS Editor. That's why I think it is better to make official releases strictly with particular MSVS.
« Last Edit: 17 Mar 2017, 09:59 by Crimson Wizard »

Monsieur OUXX

  • Cavefish
  • Mittens Vassal
  • Mittens Half Initiate
    • I can help with proof reading
    •  
    • I can help with translating
    •  
    • I can help with voice acting
    •  
Right now it is MSVS 2008 SP1, but I just removed all restrictions in the master branch (precompiled libs), so you can use any.
I was thinking about upgrading to MSVS 2015 Community Edition.
Yes I think it'd be time to upgrade, 2008 starts to be really old (I can go as far back as 2010).

It may be a good idea to include these. (...) but what should be kept in mind: because of VC redistributable packages I think it is better to make official releases strictly with particular MSVS.
did I miss something or is there a contradiction between those statements? It would be silly to create CMake scripts (and make it possible to easily create projects for every VS version) when in the end the redistributables decide of which VS is the "correct VS". That said, I would be surprised if it wasn't possible to link to a specific redistributable package, regardless of the Vs version used to edit and compile. EDIT Well it seems like it's super hard. Lol.
« Last Edit: 17 Mar 2017, 13:25 by Monsieur OUXX »