I use SVN at my job and I gotta say I kind of prefer it to Git. Feels much lighter and the commands make a lot more sense to me
SVN has 3 way merge too so this isn’t the issue it was in other VCS’s
>> The problem is all the drawbacks of trunk based development
Those were all addressed reasonably well by about 2014, e.g. upsource (my preference by far) or crucible. TeamCity’s merge after private build feature etc.
Ironically these days i see a big push to use git in a way that would work pretty well in svn too.
The biggest hassle with svn was long lived branches. Back then we encouraged devs to branch and then somehow smoosh it all back together (painful). Then we said ok do it more frequently in atomic commits (i liked that model) then DVCS took off largely in the open source world and now major dev houses (well i guess except google with p4 - but they do provide a git interface) all have come along for the ride.
Ironically with products like Stash/Bitbucket and Github Enterprise, we’re back to an SVN like model.
But I’d go even further and say: svn isn’t even a good choice for a basic feature branch workflow. Not that it’s impossible, but the added “convenience” of svn is much smaller than the gains of git.
I don’t think the “D” in dvcs is important. As you point out, most people use git with a blessed central repo because that’s what we want.
For SVN, we mostly had long-lived "release" branches. Things like pre-merge code reviews were very hard. If you wanted to send some incomplete code, you sent an email with . tar.gz file attached.
With GHE, everyone makes branches all the time. It works great for code sharing or review. And there are unique advantages too, like an ability to run a distributed set of tests on arbitrary unmerged fork/branch, which rely on branches being very cheap.
I like being able to commit while I am on a plane. (Not that this happens everyday, it’s more about the orinciple)
No central server to setup or required, period.
Whether it's doing it on your own or sharing with 100 random strangers, you don't have to setup an account for them.
Yes, SVN can handle patching, so you could email those patches also, but it's based on client-server, so someone has to setup the server and add new accounts.
Googlers have used it internally a lot as a client when their central server wasn't that, even though git itself struggled with the scale, which is why they hadn't changed over to it exclusively even server-side. If it was that complex, why would they do that?
> No central server to setup or required, period.
I've never seen a company work like this, though.
If you don't need access control, it's the easiest way to get started with source control for small teams
Someone should let every single person and organization that uses git know about this!
As a developer I love that git gives me the ability to create my own repo anywhere on any machine, just with git installed. Repos can be synced and patches exchanged in numerous ways and any decentral copy is a full backup of everything.
But as someone having worked in larger companies, there are huuge red flags with this that you wouldn't want the wrong people in your company to know about. Fully functional repos anywhere means central control is impossible. You can't just limit access in any meaningful way, you can't control info leaks, if someone can carry out a git clone on an USB stick. And full repo with history means that you always know everything about the work performance of all colleagues, past and present.
It's possible and we use it at work. Most major source control servers that support git also support user and role-based control over PR merges, force commits, etc.
There's little difference between a user that has a copy of the source as SVN and that of git, other than the git client itself allows the user to manage their commits on their local computer.
same with svn if that's your preferred workflow.
> you dont have to set up an account for them
of course not. they could just make a merge request.
Honestly I like both git and svn but I find this distinction to be contrived. I use svn in a decentralised manner daily with no problems
I only remember having to manage a server being annoying. If you're not pushing anywhere, isn't the Git workflow essentially identical, minus the server management chores?
I think you may be getting confused with CVS, where if you commit multiple files each will get its own version number like “1.34”.
Subversion creates commits across the whole repository. All files and directories you want to check in get a single revision number like “123”.
The svn file format vs the git pack format are very very different on-disk.
With git on the other hand, all the file storage is local to you machine regardless of which other remote git servers you may be using.
In addition, git blame doesn’t have to go through all history; the logical git storage model is object based on hash, so it’s really a set of queries for the contents of hash values that is used. Yes, it walks through commits, but at the lightweight metadata of trees which are akin to navigating a file system.
SVN is easier to learn and much more intuitive to use. But even if you're not a power user you get to its limits quickly. (E.g. svn afair does not support bisecting by itself, though there are external tools.) Given the world uses git you inevitably will have to learn git if you do anything with software.
I think Git is a real pleasure to use. Personally, with git-reflog, I think it's really difficult to mess up in a git repo (but, of course, if there's a will, there's a way).
I've worked with SVN on several repos and projects, and it's the VCS I like the least. It's not intuitive at all, less shell-scriptable than CVS (how do you `cvs diff -r1.{1,2} file.c` in SVN?), less portable and takes more time to setup (e.g., effectively less UNIX). I think the ViewVC interface is also one of the worst out of any other option out there, be that CVSweb or gitweb, both of which have a better usability, in my opinion. SVN repository is also a 100% monolith, unlike CVS and even unlike Git (in Git, you can't ignore individual files like in CVS, but you still can ignore unrelated branches for a checkout, for example, without the need to renumber the whole thing, which is a requirement in SVN if you want to get rid of any branch). Basically, my personal opinion, is that the monolithic and inflexible SVN is just broken by design for any distributed and large project the size of a BSD. It's still puzzling to me why it was chosen over Git back in 2008, the same year that DragonFly did select Git as replacement for CVS. If anything, with DragonFly project being smaller, they had less of a need for Git than did FreeBSD.
A merge commit is simply a commit that has more than one parent commits.
In reality, you can put whatever content on whatever commits as long as these rule don't break.
The git is just the program that you used to merge the file tree, while you can disgrace with it with '--no-commit' and modified the merged file tree as you want.
The problem is for more complex manipulations I do maybe every 6 months. The logic behind difference between commands and options is really not obvious, and some commands are very asymmetric (doing something can be simple and take one command; undoing it might take a completely different command with several options and complex references).
The concept is great and it works very well; the UI is terrible.
If only that was a thing for Perforce. There are some scripts but not really with proper streams support. Sigh.