Hmm …

Posted Nov 1, 2018 9:47 UTC (Thu) by tzafrir (subscriber, #11501)
In reply to: Hmm … by smurf
Parent article: Apache Subversion 1.11.0 released

You can easily convert the commit (revision) number to a version number. With git the only alternative I'm aware of is to use dates. This is longer and not as nice and simple (as you would expect from a decentralized system).

Hmm …

Posted Nov 1, 2018 11:49 UTC (Thu) by ballombe (subscriber, #9523) [Link] (7 responses)

With git you can use git-describe.

Hmm …

Posted Nov 1, 2018 14:58 UTC (Thu) by tzafrir (subscriber, #11501) [Link] (5 responses)

You could. Theoretically. In Subversion the value you get fits nicely inside an integer. In git this value is hardly ever used for versioning (It probably is used, but I don't recall it being used in snapshot release names. People normallyuse date/time and hope this is a good enough ID).

And no. I don't miss Subversion.

Hmm …

Posted Nov 1, 2018 18:53 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

> In Subversion the value you get fits nicely inside an integer.

Really? I mean, anything can be encoded into an integer, technically—Git commit IDs are just integers after all even if they are represented as hex strings—but I wouldn't say the base version of an arbitrary Subversion repository "fits nicely inside an integer" given its support for mixed-revision working copies and independently-versioned external references:

> $ svnversion
> 3500:4122M

That doesn't even tell you *which* parts of the working copy are from each revision, just the lowest and highest revision IDs.

Even without mixed revisions, externals, or local modifications, a single revision ID is not enough to recreate the state of the working copy: you also need to identify the repository URL and the path of the branch. Contrast that with a Git commit ID, which uniquely identifies both the content of the checkout and its history.

> It probably is used, but I don't recall it being used in snapshot release names.

I have at least 45 packages installed on my Debian system right now which use the Git commit ID as part of the package version. IIRC if you build a kernel from the Debian source package it uses the Git commit ID by default as part of the kernel version.

Hmm …

Posted Nov 1, 2018 21:03 UTC (Thu) by smurf (subscriber, #17840) [Link] (3 responses)

So SVN has monotonically-increasing version numbers. Surprise, you can do exactly the same thing on your git server if you're so inclined.

The question is, why would you want that. Unique version idenifiers do not need to be monotonic, and in most (of not all) projects not every commit needs a monotonically-increasing version number – just those you're releasing.

Hmm …

Posted Nov 2, 2018 13:56 UTC (Fri) by k8to (guest, #15413) [Link] (1 responses)

It turns out it's a really useful thing to be able to sort version numbers.

It's really useful for users, it's really useful for troubleshooting by providers, etc. Not everyone needs this property, and there are other ways to be able to deal with unsortable version numbers that are more annoying.

It's weird how many people seem to be willing to deny this utility. It's not an overwhelming concern, but it is quite useful.

Hmm …

Posted Nov 3, 2018 14:36 UTC (Sat) by mgedmin (subscriber, #34497) [Link]

I get the impression people in this thread aren't familiar with `git describe`, so here's what it gives you:

<last-version-tag-on-this-branch>-<number-of-commits-since-that-tag>-g<sha1-of-the-last-commit>

The first parts ensure that version numbers produced by `git describe` are monotonically increasing (assuming you tag your versions in a sensible way), and the last part ensures anyone can quickly locate the right commit if they want to.

Hmm …

Posted Nov 2, 2018 15:27 UTC (Fri) by tzafrir (subscriber, #11501) [Link]

I suspect git had to develop 'bisect' early on for a reason. With Subversion, manual bisecting is simpler than in git (but sure, git bisect is much nicer than manually bisecting).

Version numbers

Posted Nov 4, 2018 9:32 UTC (Sun) by tialaramex (subscriber, #21167) [Link]

As an example the Haiku operating system project adopted git reluctantly and the old guard pushing back insisted they import their practice of assigning monotonically increasing revision numbers, so every single push to their online repo (I believe the github mirror lacks this) has a git tag 'hrevN' where N is a monotonically increasing integer.

Now, fortunately (?) for them Haiku is developed rather slowly, after 17 years they have only just over 50 000 of these revisions, the number would be pretty out of control for a project like Linux - but this approach is definitely viable for your own small projects where revisions above 1000 aren't likely.

But one other notable thing about Haiku is that development has proceeded in a largely linear fashion for those 17 years. Git makes branching easy, but Haiku's politics make it hard; there is a clear mandate for the project's original concept (reproduce the 1990s BeOS R5) but beyond or outside of that things quickly get sketchy. So there's an uneasy process whereby other changes, orthogonal to that concept, either get accepted into their mainline warts and all very early, or are abandoned and decay quietly.

Haiku branched for Haiku R1 Beta 1 back in September, but there are no monotonically increasing revision numbers on that branch, it's just all labelled "Haiku R1 Beta 1" without distinguishing.