6 ms·

> I don't think anyone wants to go back to the bear skins and stone knives of centralized version control they can't effectively use from a modern system. When

> I don't think anyone wants to go back to the bear skins and stone knives of centralized version control they can't effectively use from a modern system. When working on a small team with everyone in the same office, there was nothing wrong with cvs, rcs, SourceSafe, Subversion, etc.

mkbosmans 5y ago
When I needed to work with a subversion the last time, I always found myself using git and git-svn when interacting with the version control system. It's not just the familiarity of the commands, but also the enormous flexibility you get in doing local operations to create and amend your commit history. And the speed of operations of course.
jiggawatts 5y ago
It's a classic case of a system designed for the largest scales being adopted by 2-person teams because it's "hip to be just like the big boys". Git was intended for distributed development amongst literally tens of thousands if not hundreds of thousands of programmers. Centralised SCMs worked just fine for typical dev teams of 2-15 people. I've rarely seen a team that actually utilises even 10% of Git's features. Conversely, when they accidentally trip over the inherent complexity of a distributed SCM they always cause a giant mess and end up "fixing" it in bad ways. https://xkcd.com/1597/ https://xkcd.com/1597/
- xcambar 5y ago
  Git has become so ubiquitous that I'd find it weird if a recent project was using anything else. Even if most devs don't know even 10% of it (I'm in this category and I don't care), same goes with my car: It can drive very fast but I limit its speed to something I can control. The analogy is a bit weak but in general I see no problem not using something to it's full potential.
- kamray23 5y ago
  Eh, Git works, which is all it has to do. The reason you see typical small dev teams use Git is because they're familiar enough with it from dealing with FOSS. And when you are doing FOSS, there's almost no contest – Git destroys the competition for n-person teams when n → ∞. Besides, it's not even all that complex, there's just an abundance of bad information talking about "diffs" and "branches containing commits" and confusion over the word 'tracking', when most of that is either a convenient representation or an internal implementation detail that doesn't matter at all to the user. Also, compose key flex.
  - xcambar 5y ago
    > Also, compose key flex. Care to elaborate?
    - b3n 5y ago
      Likely referring to the compose[1] key in X11. [1] https://wiki.debian.org/XCompose https://wiki.debian.org/XCompose
      - xcambar 5y ago
        Thx, but my request was more like "how do Compose and git relate?"
        b3n 5y ago
        They don't, OP was simply proud of typing "n → ∞".
        xcambar 5y ago
        :D
  - gwright 5y ago
    > confusion over the word 'tracking' OMG. This was one of my stumbling blocks in learning git. None of the explanations were helpful to me. The other area that is a tremendous source of confusion is rebasing being described as "re-writing" history. There is no re-writing of anything in git during a re-base. There is some moving of labels (branches), which you might call "re-labeling" but all the commits that were there before a rebase are still there after in the git repository as well as a bunch of new commits.
- frant-hartm 5y ago
  If the only branch you have is master/trunk then maybe. But as soon as you have multiple maintenance/feature branches I find git superior to SVN by orders of magnitude even for solo development. Merge that usually just works, can be easily aborted, rebase, cherry-pick ... Also having a local copy results in much nicer history, especially when combined with rebase.
  - hibbelig 5y ago
    The fact that all git operations are local (will except push, pull, fetch) and thus mistakes do not enter the (remote) repo so often, that’s really a great advantage. But what is the problem regarding merges?
    - WorldMaker 5y ago
      Few centralized source control systems ever adopted the "three-way merge" which is the big thing that makes git merges seem relatively magic in comparison. It was an evolutionary pressure thing: not implementing it in a centralized system was a local maxima, when centralized it is easy enough to constrain merges to easier to reason with "two-way merges", and implementing "three-way merges" was a lot of work for little gain (it didn't sell enough of the centralized tools you never heard of or no longer remember that did invest into it). Meanwhile when assuming merges are distributed and entirely offline-first decentralized source control systems had to invest into the "three-way merge" problem and at this point git has invested more than just about any other source control system this side of "academia" (and source control systems you don't hear much about these days like darcs/pijul). git makes merges much easier through a lot of hard work on its part because it has to in order to survive. A lot of centralized systems were really bad at merges but we put up with it because it mostly worked and it was "good enough".
      - hibbelig 5y ago
        Svn does do three-way merges, see the section "External diff" in the svn book. One thing I found in svn but couldn't find in git is merge tracking: you can merge individual commits and svn records which commits have been merged. The equivalent operation in git would be cherry-picking, and I believe git does not track metadata on cherry-picked commits. Example: I have a branch A, and I've branched B off from A. B has extra commits x, y, z (in that order). I merge commit y into branch A. (In git, I would have to cherry-pick that commit.) Then I merge the whole branch into A. Now svn knows that y has already been merged, so it only tries x and z. But git (AFAIK!) attempts to apply all three changes, and then detects based on the file content that change y was already present. In svn, due to merge tracking, I can merge commit y into branch A and also make changes to the code in the process, and svn still knows to skip y on the final "full" merge.
- scoopertrooper 5y ago
  I worked with SVN briefly as it was out of fashion by the time I entered the workforce, but one thing I remembered about SVN was that there was a lack of standardisation between the clients. I created the project using tortoiseSVN and any time a team member tried to add to it using a different client than tortoiseSVN it'd corrupt the entire repository!
  - mkbosmans 5y ago
    That doesn't sound right. Actual corruption of the repository can happen, but not by simply using another client than your team members. May be you mean something more alike commiting non-standard line endings? That can easily happen in git too, e.g. when the .gitattributes is different between worktrees.
    - scoopertrooper 5y ago
      May have been the case, it was about a decade ago now! Somehow tortoiseSVN solved those issues, perhaps they had some smarts to normalise the line endings? In any event, I've never had a git repo become corrupted in such a way after many years of continuous usage, but SVN seemed to fall over in a light breeze.
- ozim 5y ago
  One point to add to the XKCD - driving an automatic transmission car is "steering wheel, gas pedal, break". Most people don't even realize that there are micro explosions there around 2k times per minute let alone rest of the magic that happens in a modern car. No one reads car manual and probably no one uses most of options in their cars. But still it is such a useful tool that many cannot live without one just like nowadays devs cannot live without GIT. So I think it is perfectly fine to use only couple commands and don't even think about distributed graph and then adjust/learn when you need to understand more.
- globular-toast 5y ago
  > It's a classic case of a system designed for the largest scales being adopted by 2-person teams because it's "hip to be just like the big boys". People are still saying this? I remember hearing this around 2007 when I started to use git. It's completely wrong. How would I, as a single developer alone, even use CVS or SVN? Have my own server running locally? I tried that and it sucked. Maybe there's some other tool I could use instead, well now I have to learn two tools. Git is popular because it works at all scales.
dspillett 5y ago
While I agree with your main point, as someone who used SourceSafe in the past I strongly dispute the claim there was nothing wrong with it, relative to the others that you mention!
ozim 5y ago
From my perspective SVN merges were absolute ape show even with as small as 5 people in the team. Internet down - cannot do anything because you cannot even commit stuff with subversion. Let alone some totally obscure version control software I was working with as well. Yes it was better than making copies of source code with date/time. What is my killer feature for GIT: that I can work on my local repo and I can do whatever I want there. Only when I have to share the code I have to cleanup commits/code. In general I probably could do the local repo with SVN and moving changes between them would be more hassle than worth probably. Also as young dev I did not thought about that until I saw workflows in GIT and it blew my mind.
- berkes 5y ago
  > Internet down - cannot do anything because you cannot even commit stuff with subversion. That, in itself, I consider a poor argument. The obvious solution would be to ensure Internet does not go down. However, as an important design precondition, it forces the builder of such a system to embrace asynchronous, eventual consistency etc. Which leads to a much better design, even if your internet is 99.9999% available. I'm convinced the "offline" requirements are the reason merging, rebasing, etc are so well done in Git.
  - dataflow 5y ago
    "Well done" might be overstating things... they're better than other tools alright, but if I only had a dollar for every single time I saw a poor git diff. Forget language-aware diffing; the line-level diffing doesn't even seem to handle even the dumbest cases of indentation and brace-matching with any intelligence when merging. They have a lot of low-hanging fruit for improvement.
  - onion2k 5y ago
    The obvious solution would be to ensure Internet does not go down. If your argument is "The solution to the problem is to not have the problem." then something is wrong with the way you're thinking about the problem.
    - 5y ago
balfirevic 5y ago
There is plenty wrong with them even when working alone.
- TedDoesntTalk 5y ago
  Honest question: such as what? Some enormous projects were written with CVS (concurrent version control) including, IIRC, Unix system V and some Jet Propulsion Lab projects
  - balfirevic 5y ago
    The same things that are wrong with them when working in a team. I want to do experiments in separate branches, sync them across my desktop and laptop, merge them painlessly, merge various bug fixes to those branches and go through history without having to go make a cup of coffee while I'm waiting. And most importantly, I don't want those things to be any more pain in the ass than they need to be - and they are more painful in CVS, Subversion and SourceSafe. Of course complex software can be written without Git - I've been writing software since before Git existed. It can also be (and has been) written without, say, lexical scoping. But it's just harder. Out of curiosity, the other day I wrote a script that goes through each git commit in a repository and calculates how many lines of code there are, so I can see how it changed over time. That'd be fun in SVN.
badsectoracula 5y ago
Yeah, i've worked with SVN projects both in office and in open source projects and i use it for a couple of my own projects where i have a lot of binary files (the common alternative to this with git is something like git-lfs but that is essentially sticking a cvcs into a dvcs while pretending you are only using the dvcs... and when it comes to dvcs i prefer fossil anyway) and i never really saw anything wrong with SVN. I might have been lucky, but that is a luck that goes back decades :-P

mkbosmans 5y ago

When I needed to work with a subversion the last time, I always found myself using git and git-svn when interacting with the version control system. It's not just the familiarity of the commands, but also the enormous flexibility you get in doing local operations to create and amend your commit history. And the speed of operations of course.

jiggawatts 5y ago

It's a classic case of a system designed for the largest scales being adopted by 2-person teams because it's "hip to be just like the big boys". Git was intended for distributed development amongst literally tens of thousands if not hundreds of thousands of programmers. Centralised SCMs worked just fine for typical dev teams of 2-15 people. I've rarely seen a team that actually utilises even 10% of Git's features. Conversely, when they accidentally trip over the inherent complexity of a distributed SCM they always cause a giant mess and end up "fixing" it in bad ways. https://xkcd.com/1597/ https://xkcd.com/1597/

xcambar 5y ago
Git has become so ubiquitous that I'd find it weird if a recent project was using anything else. Even if most devs don't know even 10% of it (I'm in this category and I don't care), same goes with my car: It can drive very fast but I limit its speed to something I can control. The analogy is a bit weak but in general I see no problem not using something to it's full potential.
kamray23 5y ago
Eh, Git works, which is all it has to do. The reason you see typical small dev teams use Git is because they're familiar enough with it from dealing with FOSS. And when you are doing FOSS, there's almost no contest – Git destroys the competition for n-person teams when n → ∞. Besides, it's not even all that complex, there's just an abundance of bad information talking about "diffs" and "branches containing commits" and confusion over the word 'tracking', when most of that is either a convenient representation or an internal implementation detail that doesn't matter at all to the user. Also, compose key flex.
- xcambar 5y ago
  > Also, compose key flex. Care to elaborate?
  - b3n 5y ago
    Likely referring to the compose[1] key in X11. [1] https://wiki.debian.org/XCompose https://wiki.debian.org/XCompose
    - xcambar 5y ago
      Thx, but my request was more like "how do Compose and git relate?"
      - b3n 5y ago
        They don't, OP was simply proud of typing "n → ∞".
        xcambar 5y ago
        :D
- gwright 5y ago
  > confusion over the word 'tracking' OMG. This was one of my stumbling blocks in learning git. None of the explanations were helpful to me. The other area that is a tremendous source of confusion is rebasing being described as "re-writing" history. There is no re-writing of anything in git during a re-base. There is some moving of labels (branches), which you might call "re-labeling" but all the commits that were there before a rebase are still there after in the git repository as well as a bunch of new commits.
frant-hartm 5y ago
If the only branch you have is master/trunk then maybe. But as soon as you have multiple maintenance/feature branches I find git superior to SVN by orders of magnitude even for solo development. Merge that usually just works, can be easily aborted, rebase, cherry-pick ... Also having a local copy results in much nicer history, especially when combined with rebase.
- hibbelig 5y ago
  The fact that all git operations are local (will except push, pull, fetch) and thus mistakes do not enter the (remote) repo so often, that’s really a great advantage. But what is the problem regarding merges?
  - WorldMaker 5y ago
    Few centralized source control systems ever adopted the "three-way merge" which is the big thing that makes git merges seem relatively magic in comparison. It was an evolutionary pressure thing: not implementing it in a centralized system was a local maxima, when centralized it is easy enough to constrain merges to easier to reason with "two-way merges", and implementing "three-way merges" was a lot of work for little gain (it didn't sell enough of the centralized tools you never heard of or no longer remember that did invest into it). Meanwhile when assuming merges are distributed and entirely offline-first decentralized source control systems had to invest into the "three-way merge" problem and at this point git has invested more than just about any other source control system this side of "academia" (and source control systems you don't hear much about these days like darcs/pijul). git makes merges much easier through a lot of hard work on its part because it has to in order to survive. A lot of centralized systems were really bad at merges but we put up with it because it mostly worked and it was "good enough".
    - hibbelig 5y ago
      Svn does do three-way merges, see the section "External diff" in the svn book. One thing I found in svn but couldn't find in git is merge tracking: you can merge individual commits and svn records which commits have been merged. The equivalent operation in git would be cherry-picking, and I believe git does not track metadata on cherry-picked commits. Example: I have a branch A, and I've branched B off from A. B has extra commits x, y, z (in that order). I merge commit y into branch A. (In git, I would have to cherry-pick that commit.) Then I merge the whole branch into A. Now svn knows that y has already been merged, so it only tries x and z. But git (AFAIK!) attempts to apply all three changes, and then detects based on the file content that change y was already present. In svn, due to merge tracking, I can merge commit y into branch A and also make changes to the code in the process, and svn still knows to skip y on the final "full" merge.
scoopertrooper 5y ago
I worked with SVN briefly as it was out of fashion by the time I entered the workforce, but one thing I remembered about SVN was that there was a lack of standardisation between the clients. I created the project using tortoiseSVN and any time a team member tried to add to it using a different client than tortoiseSVN it'd corrupt the entire repository!
- mkbosmans 5y ago
  That doesn't sound right. Actual corruption of the repository can happen, but not by simply using another client than your team members. May be you mean something more alike commiting non-standard line endings? That can easily happen in git too, e.g. when the .gitattributes is different between worktrees.
  - scoopertrooper 5y ago
    May have been the case, it was about a decade ago now! Somehow tortoiseSVN solved those issues, perhaps they had some smarts to normalise the line endings? In any event, I've never had a git repo become corrupted in such a way after many years of continuous usage, but SVN seemed to fall over in a light breeze.
ozim 5y ago
One point to add to the XKCD - driving an automatic transmission car is "steering wheel, gas pedal, break". Most people don't even realize that there are micro explosions there around 2k times per minute let alone rest of the magic that happens in a modern car. No one reads car manual and probably no one uses most of options in their cars. But still it is such a useful tool that many cannot live without one just like nowadays devs cannot live without GIT. So I think it is perfectly fine to use only couple commands and don't even think about distributed graph and then adjust/learn when you need to understand more.
globular-toast 5y ago
> It's a classic case of a system designed for the largest scales being adopted by 2-person teams because it's "hip to be just like the big boys". People are still saying this? I remember hearing this around 2007 when I started to use git. It's completely wrong. How would I, as a single developer alone, even use CVS or SVN? Have my own server running locally? I tried that and it sucked. Maybe there's some other tool I could use instead, well now I have to learn two tools. Git is popular because it works at all scales.

dspillett 5y ago

While I agree with your main point, as someone who used SourceSafe in the past I strongly dispute the claim there was nothing wrong with it, relative to the others that you mention!

ozim 5y ago

From my perspective SVN merges were absolute ape show even with as small as 5 people in the team. Internet down - cannot do anything because you cannot even commit stuff with subversion. Let alone some totally obscure version control software I was working with as well. Yes it was better than making copies of source code with date/time. What is my killer feature for GIT: that I can work on my local repo and I can do whatever I want there. Only when I have to share the code I have to cleanup commits/code. In general I probably could do the local repo with SVN and moving changes between them would be more hassle than worth probably. Also as young dev I did not thought about that until I saw workflows in GIT and it blew my mind.

berkes 5y ago
> Internet down - cannot do anything because you cannot even commit stuff with subversion. That, in itself, I consider a poor argument. The obvious solution would be to ensure Internet does not go down. However, as an important design precondition, it forces the builder of such a system to embrace asynchronous, eventual consistency etc. Which leads to a much better design, even if your internet is 99.9999% available. I'm convinced the "offline" requirements are the reason merging, rebasing, etc are so well done in Git.
- dataflow 5y ago
  "Well done" might be overstating things... they're better than other tools alright, but if I only had a dollar for every single time I saw a poor git diff. Forget language-aware diffing; the line-level diffing doesn't even seem to handle even the dumbest cases of indentation and brace-matching with any intelligence when merging. They have a lot of low-hanging fruit for improvement.
- onion2k 5y ago
  The obvious solution would be to ensure Internet does not go down. If your argument is "The solution to the problem is to not have the problem." then something is wrong with the way you're thinking about the problem.
  - 5y ago

balfirevic 5y ago

There is plenty wrong with them even when working alone.

TedDoesntTalk 5y ago
Honest question: such as what? Some enormous projects were written with CVS (concurrent version control) including, IIRC, Unix system V and some Jet Propulsion Lab projects
- balfirevic 5y ago
  The same things that are wrong with them when working in a team. I want to do experiments in separate branches, sync them across my desktop and laptop, merge them painlessly, merge various bug fixes to those branches and go through history without having to go make a cup of coffee while I'm waiting. And most importantly, I don't want those things to be any more pain in the ass than they need to be - and they are more painful in CVS, Subversion and SourceSafe. Of course complex software can be written without Git - I've been writing software since before Git existed. It can also be (and has been) written without, say, lexical scoping. But it's just harder. Out of curiosity, the other day I wrote a script that goes through each git commit in a repository and calculates how many lines of code there are, so I can see how it changed over time. That'd be fun in SVN.

badsectoracula 5y ago

Yeah, i've worked with SVN projects both in office and in open source projects and i use it for a couple of my own projects where i have a lot of binary files (the common alternative to this with git is something like git-lfs but that is essentially sticking a cvcs into a dvcs while pretending you are only using the dvcs... and when it comes to dvcs i prefer fossil anyway) and i never really saw anything wrong with SVN. I might have been lucky, but that is a luck that goes back decades :-P