Hacker News Reader

Comment by binaryturtle | Hacker News Reader

I use Subversion w/o a server too. You can have your repositories locally (file:///Path/to/repository). All my own (single man) projects are in local SVN repositories. For my use case git is just too much extra friction, and I still love to have my one single unique global revisions number that is linearly increasing with each commit. :)

View on HN

I loved the simple increasing numbers of Subversion. This was better then CVS "ad-hoc" versioning and also far better then git's hashes. Single numbers are easy for humans. I would love git would make it possible to work that way (there is one way: `git describe` can show something like "v1.0.4-14-g2414721" which means "14 commits ahead of tag v1.0.4".)

Some form of "increment authority" that simply appends to a list of hashes whenever it encounters a commit not yet on the list? Then you could use URI like $authorityhost/orderedcommits/$number as synonyms for the hashes. Multiple increment authorities would not necessarily have them in the exact same order (and "current latest" would likely differ by an order of magnitude or two after some time if you ever had multiple authorities), but it would still provide a lot of intuitive understanding.

I wonder how the tag mechanism would perform if you just burned it with this content. I suspect that it would not perform well...

Mercurial has serial numbers which work like this ("revision numbers"), but you can only see your local repo's serial number. There's no concept of a public revision number authority.

My release code uses `git rev-list --count $tag` to output the release number.

Ironically, GitHub became popular because it gave everyone a centralized repo—exactly the thing people liked about SVN.

It used to be possible to use GitHub via svn too (but I think they removed that feature a while ago.)

It's so weird. Git's major differentiating feature is that its distributed nature means you don't need a centralized server, and your work isn't blocked if that (unneeded) centralized server goes down. Yet, so many developers have twisted git around to make it a centralized single point of failure--on purpose! I don't understand it.

Git still works offline when github is down. Try committing or getting history when the svn server is down, let alone pushing to a different remote. The things github centralizes are the things that aren't actually git itself.

Yes but the .svn dirs everywhere keep being annoying

Since Subversion 1.7 (2011), working copies only use a single .svn directory at the top level.

Amazing! I remember copying over a project and failing to clean all the .svn folders... Messed up 2 projects at a price of one :D

git rev-list --count HEAD

Reply on news.ycombinator.com