Policy regarding git branching and Visual Studio project upgrade

Started by Monsieur OUXX, Thu 16/03/2017 16:24:59

Previous topic - Next topic

Monsieur OUXX

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

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.

Monsieur OUXX

Quote from: Crimson Wizard on Thu 16/03/2017 18:26:27
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

Quote from: Monsieur OUXX on Thu 16/03/2017 20:54:00
Quote from: Crimson Wizard on Thu 16/03/2017 18:26:27
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

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.

 

Crimson Wizard

Quote from: Monsieur OUXX on Fri 17/03/2017 09:30:38
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.

Quote from: Monsieur OUXX on Fri 17/03/2017 09:30:38
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.

Monsieur OUXX

Quote from: Crimson Wizard on Fri 17/03/2017 09:57:41
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).

Quote from: Monsieur OUXX on Fri 17/03/2017 09:30:38
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.
 

SMF spam blocked by CleanTalk