[News] MediaPortal 1.2.1 final released! (1 Viewer)

[chrik]

Take your time 1.20 is very stable!

 

[Oxan]

Re: AW: MediaPortal 1.2.1 final released!

We also had to develop our own solution for a "readable revision numbering" which does not exist in that way for git.
And then there is the identification of which branch the build someone uses for testing came from + a lot more.

That's not really true. If you need more readable revision numbering then the commit hash (which I have never needed since I became a bit more used to git), you can use git describe. You won't get something more readable with a distributed VCS, because there isn't something that's more clear. Same thing holds true for branch identification: the branch name in itself is totally useless. I can name my local branches whatever I want. Only with the commit hash you can trace it down to a specific point in your repository (or conclude that I run with local changes).

 

[infinite.loop]

Oxan What I meant with branch name identification is that all MediaPortal logs include info from which branch the version was built.

 

[tourettes]

Re: AW: MediaPortal 1.2.1 final released!

you can use git describe.

git-describe is not robust enough when there are merges done. It wont find out the correct ancestor (it picks falsely the closes one). We (arion) have implemented custom script to handle that - https://github.com/MediaPortal/MediaPortal-1/tree/master/Tools/Script & Batch tools/DeployVersionGIT

(there will be a public announcement of the GIT soon...)

You won't get something more readable with a distributed VCS, because there isn't something that's more clear. Same thing holds true for branch identification: the branch name in itself is totally useless. I can name my local branches whatever I want. Only with the commit hash you can trace it down to a specific point in your repository (or conclude that I run with local changes).

Builds are done only from the master repository and there the branches are always going to follow the specified naming convention. Local builds aren't so much interest since devs who create such should be already knowing what they contain.

 

[Oxan]

Re: AW: MediaPortal 1.2.1 final released!

@Oxan What I meant with branch name identification is that all MediaPortal logs include info from which branch the version was built.

With your build system it should be quite easy to integrate that. Just run git.exe symbolic-ref HEAD and put the output of that somewhere in a global file. Maybe strip the refs/heads/ part when printing it in the logs, but that's also quite easy. Given that you already use batch scripts for building it shouldn't have been much work.

git-describe is not robust enough when there are merges done. It wont find out the correct ancestor (it picks falsely the closes one). We (arion) have implemented custom script to handle that - https://github.com/MediaPortal/MediaPortal-1/tree/master/Tools/Script & Batch tools/DeployVersionGIT

Yeah, I saw that and that was the main reason for my comment. I don't really get why all these tricks are done here. It seems to be like git describe but then only to follow the branch line on the first parent of the merge. This shouldn't be really necessary: not only is the order of parents in a merge not guaranteed afaik, I also can't think of a case where searching all ancestors would lead into a problem. The current code will probably go wrong when you branch off 1.2.0, then do some commits and then merge 1.2.1. It will use the 1.2.0 tag instead of the 1.2.1, which your branch is really based upon. (Some might argue that rebasing is better in this scenario and on some level I agree with that, but that isn't always an option for long-living branches).

Builds are done only from the master repository and there the branches are always going to follow the specified naming convention. Local builds aren't so much interest since devs who create such should be already knowing what they contain.

Sure, that's true for your builds. But consider this scenario a not very experienced (non-MP) developer who clones the git repository, does some changes on his master branch, and sees that something apparantly totally unrelated is broken (because of his changes but he doesn't know that). He posts the logs to the MP forum, in which is only the branch name (master), so the support people think it's a build from the official repository. If you add the commit hash to the logs, they can see that it's a local build with changes and explain to him that he should use a build from official sources if he wants support.
One of the things that usually happen when you switch to a distributed VCS is that a lot more people are going to use local builds. (Here, I'm one of them. Now do I know that you can't support my local builds and I should try the offical builds when reporting bugs, but there are a lot of people who don't).