> but at that point we're re-inventing subversion
So? Maybe Subversion is all most developers need?
So? Maybe Subversion is all most developers need?
Git doesn't even technically have branches, just pointers to commits which can easily get mixed up, go headless and fail out in ways that just never happened in SVN.
And rebasing a branch with several commits can be a nightmare since you have to re-merge almost (but not exactly) the same code over and over again at whatever state it was in at some time in the past when some previous commit happened - unless you abort out and squash first. In SVN, you just merged the whole branch once and when both were in their final current state.
Of course, git's a lot more powerful, but with that comes complexity. SVN branching and merging was a snap comparatively.
* https://subversion.apache.org/docs/release-notes/1.10.html#c...
* https://subversion.apache.org/docs/release-notes/1.11.html#c...
I mean, if that's a reason to say git doesn't technically have branches, then neither does svn. It has subdirectories that you can make copies of at any level, and copy commits between them at any level, such that you can make an amazing repo-within-a-repo mess not possible in git.
Sure, CVS was limited but it was reliable and straightforward.
It was so reliable that people complained about SVN using a DB (Berkeley DB) as backend, as manual fixing of CVS files was a "normal" part of operation and people didn't believe that might not be needed ...
Like I’m gonna bother to set up a Subversion remote for every little repo that I create for myself.
This means you usually only have one svn repo, and you set it up the way you like. As an example, you may set things up so you can checkout:
server:/proj/small/hello - to get a single project
server:/proj/small- to get all small projects
server:/proj - to get all projects
If you already have one of those checked out, adding new project is as simple as "mkdir bar", "svn add bar", "svn commit". So juch easier than making new github repo. And multi-level hierarchical project nesting is still something impossible in git.
Were you paying attention to what I just wrote!? `git init`. What do I need a remote on the Internet for?
But yes, if all your work is on one machine, and you have backups of it, there is not much point in svn.
Being distributed, it solved the main gripes with SVN; it also added a better merging algorithm (https://foswiki.org/pub/Development/SVK/svk-visual-guide.pdf), solving another big gripe.
I was actually satisfied of it, and surprised that it never got attention, in particular, because there were no requirements in order to use it with existing SVN repositories. I'm actually baffled, because SVN is still active, so SVK would still be useful nowadays.
I used subversion for a long time and was resistant to moving ardour.org to use git instead. 24hours after we switched (we never use 3rd party git hosting as our canonical repo), I was already convinced it was not the right choice, but an excellent choice.
Sure, we use one canonical repository. All our “pull requests” are really merge requests, mostly to the main branch. So that’s pretty centralized, right? So why use a distributed VCS? Well, why use a local editor or IDE for code that is ultimately going to end up in the cloud somewhere? Sure, you might want to out of preference, but why should you be forced to? The fact is that wherever the code will end up is besides the point when it comes to how to develop it.
The truly important thing about distributed VCS is that it forces almost all of the operations on the repository to be usable locally. And why should it not be? What’s “git log”, “git blame”, or “git merge” got to do with whether there is one canonical repo or a hierarchy of upstreams?
I think that this idea that non-distributed VCS is somehow the default—as in the obvious, simple thing to implement—is just backwards. Of course the default assumption for any VCS operation—unless it has a name like “send-email”—should be that it operates on your own local copy.
Sure, we use a centralized repo structure. And the only call-central-command operation I use is “git push”. All the other fiddling and querying—and all the things that make version-control-as-history useful—is local.
I think there is a reason why this XKCD was made: https://xkcd.com/1597/
It will work fine over a Windows share, Samba, NFS, and so on. It doesn’t need svn or http protocol to operate.
SVN doesn't work peer-to-peer or over email. And that's fine. It's just not ready to go with only local tools.
Of course, you can use GitHub with Subversion just fine, but that wasn't the point. The point was that Subversion alone is never enough if you want to collaborate.
That’s a bummer. It would help us point the discussion in the right direction.
> SVN doesn't work peer-to-peer or over email.
Why not? What is so different about people having their own subversion repositories over file protocol vs people having their git repositories?
Why would you not be able to send a subversion patch in an email?
As someone who uses git for 10 years, I understand it may not be as ergonomic as with git. But why not?
> The point was that Subversion alone is never enough if you want to collaborate.
Why not? Is git enough?
Older systems like CVS are also still in use, but it appears that none of the old systems really lasted more broadly and aren't useful for the needs of today.