Hacker News Reader

Comment by rhabarba | Hacker News Reader

> unfortunately still Subversion

Which is a better choice than Git for most projects, to be honest.

Everyone's has their own tastes and preferences, of course, and I respect that yours is different than mine. That said, I used and loved CVS and then SVN for years and didn't get why all the kids were fussing around with this new Git thing. I finally made myself try it for about a week. At the end of that experiment, I ported all my repos from SVN to Git and quickly set to purging all Subversion-related knowledge from my brain. There's literally nothing about SVN that I prefer to Git, other than its UI was a little more pleasant.

I actually LIKED having a central repository, which many of us still seem to prefer (i.e. GitHub, GitLab, Bitbucket). I switched to git mainly because my colleagues were all using it. I found it difficult to use, at first, because of my expectation of a central repo. Many years in, however, I see extreme value in having all your history locally. Specifically, never having to worry about a server crashing or your "host" going out of business.

Same. I didn't get what was better about a distributed system for small projects, until it fully clicked with me that my copy was just as "official" as any other sitting around, and that any "server" was a copy that we collectively decided was going to be the one of record. I can't imagine any plausible scenario in which I'd go back to having a central SVN-style server.

Having an official central server is precisely what you want in most development environments. Being able to go back to any prior version of the code is tremendously useful and something git can't do.

Having history available locally also means you can perform interesting operations on history -- like "git blame" -- without making the server do all the heavy lifting.

Yeah, other than locking I would argue that a DVCS is better at even the things a non-distributed VCS is good at.

The problem is, is that git will happily destroy history. git blame is not useful because it doesn't tell you who authored the line of code.

Right, especially after a "squash", which seems to be the standard way to merge branches in the companies I've been working with recently. (Which is, ironically, also the way Subversion merges branches. With the exception that "svn blame -g" will go into the commits which were squashed if you want. An option which doesn't exist after a "squash" on Git.)

> The problem is, is that git will happily destroy history.

No, people will happily destroy history. Git is just a tool.

Fossil's opinion on this is that history is an immutable record of project history. It may be messy and unfortunate at times, but it is what happened, and it shouldn't be altered in place any more than you'd do that with an accounts ledger.

In extremis, Fossil offers the "shun" command to remove improperly-committed artifacts, but even then it's subject to a lot of restrictions. (https://fossil-scm.org/fossil/doc/trunk/www/shunning.wiki)

> Fossil's opinion

Tools don't have opinions, people do. Fossil is just inflexible.

You don't want to alter history? Don't do it then. Git supports not altering history just fine.

I can't control what other users of the repo are doing, so it's not that simple.

If you are their superior, other users disregarding your orders is s social problem, not a technical one. If you aren't, it's a good thing they are able not to do what you want.

Tools being more flexible is strictly a good thing. If they are misused, the person that misused them is responsible. It is that simple.

> I actually LIKED having a central repository, which many of us still seem to prefer (i.e. GitHub, GitLab, Bitbucket).

You're confusing a hosting service with being forced to use a centralized repository.

Take GitHub, for example. If git was centralized them you would not have forks, multiple remotes or multihosting, or could even work independently of the remote server.

With Git, you can even set up a repo in a network file system somewhere, or even a USB thumbrive.

Git makes it easier to do a fork but you could certainly fork a subversion repo. I’m fairly certain you could sort of a merge process across multiple upstreams.

Git does far more than making it easy to fork: it makes it trivial and inexpensive.

Meanwhile SVN supports forking in the sense that it supports copying directories.

The "fork" concept is not native to neither Subversion nor git.

You are probably thinking of branches and tags, and those are used similarly in both systems. They are a bit more convenient in git since they are created in constant as opposed to linear time.

Copies in Subversion are only metadata. Since partial clones are native to the system, it is simple to present both branches and tags as file paths. It was likely considered an easy user interface. Everything is a file and all that. In comparison, git users must learn the git object naming scheme, otherwise things can end up very confusing should you have a directory and a branch with the same name.

> They are a bit more convenient in git since they are created in constant as opposed to linear time.

I would argue that branches are nicer in git because it makes merging so much easier.

> You are probably thinking of branches and tags,

No, I was referring to forking projects, in the sense that Git allows for creating brand new and independent repositories that clone the version history up to a point in time and enable to add the origin Git repository as a remote repository.

SVN also does not support branching or tagging, as it actually supports only copying directories around a file system.

For most of us, even with DVCS there is one copy of the repos that is more important than all the rest - the one attached to the CI or deployment tools. It’s only decentralized as long as this copy has only short periods of unavailability. Hours are bad, days are much worse.

Linus seems to have a very different development model than almost all of the rest of us. And if Linus is asynchronous, then so is the codebase he maintains.

If you or I have eight different PRs going it’s because we have eight different promises being made to customers. Rejecting them has real consequences that we feel. For Linux many of those are externalities.

> Which is a better choice than Git for most projects, to be honest.

That's pretty subjective. Most engineers I interact with personally know how to use Git but not SVN. I'd argue the opposite is true base on my subjective experience.

Really depends on where/how you're using versioning, team familiarity, etc.

It took me maybe eight months before I was willing to perform open heart surgery on a subversion repo. Two years to dare to try the same thing with git, and I was much more anxious about the whole thing. At the three year mark I have the same ambivalence about things working out that I did in less than a quarter of the time with the previous system.

That’s a little too much to explain away with variability.

Disagree. SVN was always a pain. Committing is really slow and merging is bad (particularly for things like directory renames).

If all you had before was CVS then SVN wasn't a pain.

Atomic commits and file renames.

SVN had improvements over CVS, but it still had obvious pain points. So there was still an obvious opportunity for a better VCS to come along.

Sure but you could say the same about Git.

With time, the standard requirements rise and we get more demanding.

How about a VCS that not only diffs line by line but saves the diffs as editing delta?

Or that understands the syntax of the code and can differentiate a variable renaming from an actual code change?

Or connecting different repositories is hardly solved with Git. Submodules suck, grafting even more so. Or you can't make one repository out of two and keep their Git history intact.

How so?

Less overhead, a better UI.

Better support for large and binary artifacts

horrendously slow `svn log`, locking files, bad branching… I only used it when I was a student but I don't miss svn at all.

Reply on news.ycombinator.com