Running GitVersion, most of the time running, which can be quite long on large-ish codebases, is spent on looping through all version candidates on all versioning strategies on the codebase.
This includes traversing backwards using:
- FallbackBaseVersionStrategy
- ConfigNextVersionBaseVersionStrategy,
- TaggedCommitVersionStrategy
- MergeMessageBaseVersionStrategy
- VersionInBranchNameBaseVersionStrategy
- TrackReleaseBranchesVersionStrategy
Some of these are rather expensive. On our codebase at work, a lot of time is spent in MergeMessageBaseVersionStrategy. I don't think we need this, as we use tag-based versioning. We would benefit a lot being able to enable just the versioning strategy desired, alternatively a list of strategies. Not all strategies are applicable for everyone.
So, 1st suggestion is:
Making the strategies used configurable
2nd, I'd like to question if it is really necessary to loop through all previous commits in parents to find the "largest version" candidate. I am very open to being wrong here, but wouldn't the newest version found be the correct one to use for calculating the next version in 99% of all cases? At least, there could be a configurable setting to make it use the first/newest ancestor version on each strategy.
2nd suggestion is, then:
Make a config switch available to always use the newest version when calculating next
I'd be happy to take on this task, but I might need a little guidance on where I should put the new config values. Does it make sense to put them on the branch? Or globally?
I have attached a run of GitVersion of a codebase I am working on. In all strategies, it finds the correct version to use for calculating "next version" (2019.21.0) in the first try. First is after 3 secs. But it still loops through all commits in all strategies, and takes and additional 60secs (30 after my other #1838). I'd like it to stop after finding the first candidate for a strategy.
gitversion-diag.txt
Running GitVersion, most of the time running, which can be quite long on large-ish codebases, is spent on looping through all version candidates on all versioning strategies on the codebase.
This includes traversing backwards using:
Some of these are rather expensive. On our codebase at work, a lot of time is spent in MergeMessageBaseVersionStrategy. I don't think we need this, as we use tag-based versioning. We would benefit a lot being able to enable just the versioning strategy desired, alternatively a list of strategies. Not all strategies are applicable for everyone.
So, 1st suggestion is:
Making the strategies used configurable
2nd, I'd like to question if it is really necessary to loop through all previous commits in parents to find the "largest version" candidate. I am very open to being wrong here, but wouldn't the newest version found be the correct one to use for calculating the next version in 99% of all cases? At least, there could be a configurable setting to make it use the first/newest ancestor version on each strategy.
2nd suggestion is, then:
Make a config switch available to always use the newest version when calculating next
I'd be happy to take on this task, but I might need a little guidance on where I should put the new config values. Does it make sense to put them on the branch? Or globally?
I have attached a run of GitVersion of a codebase I am working on. In all strategies, it finds the correct version to use for calculating "next version" (2019.21.0) in the first try. First is after 3 secs. But it still loops through all commits in all strategies, and takes and additional 60secs (30 after my other #1838). I'd like it to stop after finding the first candidate for a strategy.
gitversion-diag.txt