Jump to content
  • Advertisement
Krohm

GitVersionTask woes. Master branch not recognized.

This topic is 455 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Uhm, where did the source control subforum go? Nice to have a modern-looking gamedev.net indeed!

Ok, let's get to the real deal. At my current job I have somewhat managed to get to something useful and to be released. I always had an issue with versioning and so I just installed GitVersion, the relative tools and its automatic MSBuild thingie GitVersionTask.

Leaving aside I'm meeting some resistance in using source control at all, our team is so small there's really no point in using anything more than the old merge/branch model. Software development around here is... curiously managed to say for the least so I had the following needs:

  1. Official builds marked as major.minor.patch
  2. Unofficial builds as (1) plus unique identifier. SHA would be perfect.

So, what I do: I merge off master to work on something, when I merge back to master that would be a 'build'. Whatever that build is released to public or not is not my concern: stuff in master is ideally official. It seems like mainline development should be my thing right? Wrong. I tried countless configurations and wasted about three hours today the end result is always some variation of (output in VS build).

Quote

Version '7.2.3+Branch.master.Sha.<snip>' specified for 'product version' is not in normal format 'major.minor.build.revision'.

My gitVersion.yml:

next-version: 7.2
mode: Mainline

I tried annotating the master branch by using gitVersion.yml 'branch:' subsection with no avail. I have however confirmed the file is being consumed by successfully altering the produced major/minor and by producing errors.

I am a bit reluctant in opening an issue on the project page as it's basically certain it's something by my side.

What am I missing?

 

By the way, after all this pain I might actually consider other versioning mechanisms. All sort of suggestions are welcome.

BranchMerge.png

Share this post


Link to post
Share on other sites
Advertisement

git itself also has some features to name an arbitrary commit, which may be useful. I think it's "git id", but not sure, and I can't easily look it up.

 

I am not so sure your "2" makes sense, for branches, you definitely want a branchname in there, since 1.2.3.abcdf has no meaning at all to understand what branch the build contains.

Given your environment, you may want to only worry about official builds, and allow anything sufficiently unique for unofficial builds.

 

In my experience, the primary profit of a VCS it is that you don't need to copy changes back and forth between developers. Secondary benefits are that you have a list of changes since the last commit nearby, and it's easy to revert to that last state, so random experiments in debugging or trying something unknown are safe. Unfortunately, git pushes you in the distributed development model, which is not always as useful as they claim.

Share this post


Link to post
Share on other sites
23 hours ago, Alberth said:

git itself also has some features to name an arbitrary commit, which may be useful. I think it's "git id", but not sure, and I can't easily look it up.

There are indeed a variety of ways, I know them as 'tags' and in theory they work... except for some reason they really don't in this specific case. I use sourcetree so it's just a matter of pushing a button.

23 hours ago, Alberth said:

I am not so sure your "2" makes sense, for branches, you definitely want a branchname in there, since 1.2.3.abcdf has no meaning at all to understand what branch the build contains.

Well the snip is a full SHA and I've had a collision already in the past (not on SHA) so I feel quite safe for the next few years! They are indeed almost unique.

23 hours ago, Alberth said:

In my experience, the primary profit of a VCS it is that you don't need to copy changes back and forth between developers. Secondary benefits are that you have a list of changes since the last commit nearby, and it's easy to revert to that last state, so random experiments in debugging or trying something unknown are safe. Unfortunately, git pushes you in the distributed development model, which is not always as useful as they claim

Absolutely true. I'd say this problem is orthogonal to being distributed or not (compare P4 or other old stuff). For our environment it's fairly convenient to have a bare repository on a shared folder: ideally we don't push short lived branches there - ideally we sync no more than a couple of times a week and push a full untagged branch with explicit merge commits. I suggest everyone to have a go; my experience with git is positive albeit I used to have a thing for Mercurial.

 

Maybe I should have made clear that GitVersionTask stamps your c# executable with proper versioning by looking at the git. It isn't even just a property setting: you can inspect the result programmatically.

 

Anyhow, I had been given unwelcome news today so I'll be slow on replying. Given my new schedule, I think I might just give up on GitVersionTask and go back on explicit version stamping. Inconvenient but I have already spent too much time in figuring out what's wrong there.

Share this post


Link to post
Share on other sites
8 hours ago, Krohm said:

There are indeed a variety of ways, I know them as 'tags' and in theory they work... except for some reason they really don't in this specific case. I use sourcetree so it's just a matter of pushing a button.

I meant something else.  I once tried to solve this same problem (in a more restrictive form than what you seem to need), and spend a day convincing git to give me the information and looking at prior art. I looked up what the end-result was again, and ended with

https://stackoverflow.com/questions/3300746/deriving-application-build-version-from-git-describe-how-to-get-a-relatively

 

Trying that on a random git repository:
 

$ git describe
fatal: No annotated tags can describe '77553282f0d267032025955f9072e05cb109cfc6'.
However, there were unannotated tags: try --tags.

$ git describe --tags
v0.60-208-g7755328

which is something like 208 commits after "0.60", which sounds fair enough.

I think I made a few more changes to get a good result, but as usual, git has a zillion options for everything.

 

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!