[somerando7]

What's better about git? I haven't used svn, but have used perforce/mercurial professionally/git professionally, and use git personally, but I find all of them to provide the same "feature set" when doing basic development: have your own branch, and merge it in to the main branch when done/reviewed.

Merging seems the same on all 3 version control systems I've used... I've heard that git branching is better(?), but haven't seen that being used anywhere really.

[coldpie]

> I haven't used svn

Yeahhhh. Svn is centralized. You must be connected to the server to do any source control work. There is no local repository, there are no local commits. Every commit is global on the server. When you make a commit, it is pushed to the server and your coworkers can fetch it. You don't make commits locally and fiddle around and then push.

Also Svn doesn't have branches per se. You just use subdirectories. It does have facilities for merging directories and managing these "branches", but it feels real weird to be switching branches with 'cd'.

It's a very different world.

A quick read: https://svnbook.red-bean.com/en/1.7/svn.tour.cycle.html

[c-smile]

> You must be connected to the server to do any source control work. There is no local repository...

That's not correct technically speaking. You can create repository on your machine - on local FS.

But of course it is more reliable to run it on server, even for yourself. If on Windows then VisualSVN is one click solution for those who just want to have that thing working.

[Aachen]

Am I understanding you correctly if I compare it to making the argument that, technically, you could run any Internet website from your laptop and network connectivity isn't actually required for using the web?

[c-smile]

I am referring exactly to "must be connected to the server to do any source control work. There is no local repository..." which is plainly wrong by any means.

SVN client supports equally well as "svn:" protocol as "file:". Server is not mandatory with SVN - you can work with repositories on your local HD or network share.

[coldpie]

"Server" was perhaps the wrong word. "Central repo", if you like, regardless of connection method. What I meant is that "svn checkout" does not make a new repository, as "clone" does in decentralized source control systems. You must interact with the central repository (wherever it is stored, locally or over the network) to do version control work.

[tpoacher]

I have used svn in a decentralised manner, pretty much as the person above me describes, for years. It's super simple to do. You create a local repo, populate it from "origin", and when you want to commit your local changes, you make a "foreign merge" request from "origin".

Your argument that this cant be done in svn because "there's a central repo" could have been translated in "git" as: "yeah you cant work on your machine without internet because you wont be able to push on github"

[duskwuff]

> Also Svn doesn't have branches per se. You just use subdirectories. It does have facilities for merging directories and managing these "branches", but it feels real weird to be switching branches with 'cd'.

Also, this means that it's possible to do some horrifying things with branches and tags, like making a merge commit which is isolated to a single directory, or checking out a tag and making a commit to it.

Hopefully no one is actually depending on these workflows being possible, because they make project history extremely hard to follow.

[kadoban]

> I've heard that git branching is better(?), but haven't seen that being used anywhere really.

How are you merging without branches?

Git is mostly faster and more flexible than svn, and the merging works far better. Unless svn's merging has improved in the past decade or so, which is entirely possible.

When I switched to git from svn, the main differences were: merging was usable, making new branches and switching branches and such were _instant_ instead of many seconds, and I could work more flexibly (git doesn't require being connected to the server).

[arcticgeek]

Yes, that’s actually the thing about branching in SVN. Everyone remembers how awful it was 10+ years ago under SVN 1.4 and earlier but has improved immensely since then. Combined with modern client tooling, i.e. TortoiseSVN, problems with merging are almost non-existent for a long time.

I certainly wouldn’t call SVN modern but it’s very well maintained and has never lost code on me. Many git-like features also exist now such as being able to stash some changes in order to pivot to something else for a bit. Except for the central server being a problem for some use-cases, SVN just works.

[somerando7]

I meant, using branches in a way that's "better" - whatever people who use git mean when they say that.

As I said, I haven't used SVN. It just seems like perforce and mercurial are basically "identical" for the ways I use them at least.

[adql]

> Merging seems the same on all 3 version control systems I've used... I've heard that git branching is better(?), but haven't seen that being used anywhere really.

Much better working merges was reason many people moved to SVN but since then SVN just got better at it