On 15/05/18 12:53, Erik Christiansen via luv-main wrote:
> Ah, I had at one stage thought of modernising from CVS to > Subversion, but after decades of using CVS to automatically merge > concurrent edits from multiple sources, I'm disappointed to hear that > Subversion is a regression in capability.
I certainly wouldn't say that.  I moved from RCS to CVS to Subversion to git and I found Subversion more capable than CVS in every respect.

> Without more experience with Git than a couple of check-outs for a > local compile, I'd still surmise that it is not a lot more > distributed than CVS if you can't "push/pull from anywhere to > anywhere". (Except that I'd have expected that a push ought to be to > everywhere, given my mental model of a development trunk (maybe > called "main") with local development on a branch, which may be > merged back into the trunk at some stage.) And given that one shared > copy of the head of the trunk is an essential resource of a VCS, then > it doesn't seem to matter functionally whether that is a networked > central copy or distributed copies forced to be identical.
But the distributed copies aren't forced to be identical; that's one of the key features of git.

https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes

The issue that Russell encountered is that git can also operate centralised servers in addition to distributed repositories, but you can't do both things with a single repository.  A normal repository can share with others, but not be a centralised server; a centralised server can't also be used as a local repository.  But you can use any number of both in any project.

Hope that helps,
                Andrew