Hmm …

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

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).