9 ms·

An overview of version control in programming

90 points by ashvardanian 5y ago

ThereIsNoWorry 5y ago
My previous employer still uses svn. It created so much headaches and frustration due to unproductivity because e.g. someone pushed a bug without testing and you unknowingly downloaded it. No way to easily reverse of course. It was my first job after University and taught me that CRUD b2b Java enterprise jobs are to avoid at all costs in the future. For what it's worth though, I had some very funny-sad stories to tell when I interviewed to get out of there after just 6 months. Never tought a versioning system could burn me out. Git is standard for very obvious reasons.
- cognomano 5y ago
  Sincere question: what does Git have that makes easy to revert the change on your example that SVN doesn’t have? I barely know Git, that’s why I ask.
  - tom_ 5y ago
    You (or anybody) can use git revert to create a new commit that undoes previous commits: https://git-scm.com/docs/git-revert https://git-scm.com/docs/git-revert Perforce has something similar too: http://ftp.perforce.com/perforce/r16.2/doc/manuals/cmdref/p4_undo.html http://ftp.perforce.com/perforce/r16.2/doc/manuals/cmdref/p4...
    - hibbelig 5y ago
      Sven also has a command for reverting a commit, ie committing the inverse of a previous commit.
      - Izkata 5y ago
        For anyone looking for it, it's not as intuitive as git. In svn, you reverse-merge the commits from the current branch's history you want to revert: svn merge -c-123 . # single commit, the second "-" is "do the merge backwards" svn merge -r123:122 . # Multiple commits in reverse order, "the change going from 123 to 122" https://stackoverflow.com/questions/13330011/how-do-i-revert-an-svn-commit https://stackoverflow.com/questions/13330011/how-do-i-revert...
  - chriswarbo 5y ago
    Git makes branching and merging easier, and the whole history is available locally. You can just ignore those buggy commits and base your work on an older version; when someone eventually fixes the bug, you can merge the bug and its fix into your changes, to become up-to-date (with the possibility of conflicts, but nothing is completely free ;) ).
- Supermancho 5y ago
  > No way to easily reverse of course. Revert to the previous version. Push as new version. Fixed? SVN was used widely and for years, prior to git. I remember the biggest problem being expensive (full copy) branching.
  - layer8 5y ago
    Creating branches is not expensive in SVN, because it’s copy-on-write (server-side). Maybe you mean switching the local working copy to a different branch?
    - Supermancho 5y ago
      > Creating branches is not expensive in SVN, because it’s copy-on-write Copy on write is an expensive operation for branching. SVN repos that are multiple gigs, in size, are a pain to create branches for.
      - layer8 5y ago
        Not sure what you mean. Copy-on-write means that no actual copy is made initially. Branching is therefore almost instant in SVN and only requires minimal storage space. Only when you modify a file within the branch (or the original) does that specific file get copied (or rather, the diff of the modification gets stored). What is slow in SVN is switching to the branch client-side, because branches are always created server-side and you still need to synch the whole contents of the branch from server to client when switching (which works similar to a regular `svn update`).
        Supermancho 5y ago
        I'm not sure what you mean either. I don't care what SVN does now, only what it did when companies abandoned it en-masse around SVN v1.6, since that's the context of my comments.
        layer8 5y ago
- vlod 5y ago
  It's one of my interview questions when applying for a job. I say something along the lines: "I know this is a ridiculous question, but do you 1) use version control and 2) what version control do you use" and then explain I have to ask these questions becz of obvious reasons.
  - tonyg 5y ago
    Nice. Sort of a reverse FizzBuzz.
  - kevin_thibedeau 5y ago
    Do you have a monorepo? Test infrastructure?
  - arthurjj 5y ago
    There's a blog post from the early 00s called The Joel Test for judging a software team. Using source control is actually the first question. Sounds like you reinvented it :) https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...
  - icedchai 5y ago
    I had a job in the late 90's at a newly formed subsidiary of a multi-billion dollar corporation. The product was cobbled together from various third party software they licensed or acquired outright, and we were customizing. You would think they'd have set up version control to at least keep track of what came from where. Nope. Here I was, a 22 year old kid, teaching people about CVS. SVN wasn't quite out yet.
    - layer8 5y ago
      Same for me in the early 2000’s. :)
      - kevin_thibedeau 5y ago
        I had a coworker hired in 2015 (with previous work experience) who had never used any revision control.
- kadoban 5y ago
  There is good git <-> svn integration. I was using git even when any of my peers or projects were on svn and they never noticed.
- icedchai 5y ago
  I once took a job at a place that had migrated from git to perforce because it was the "corporate standard." Some departments worked with large binary assets (videos, sound files) where I understand it made more sense. We were developing web apps. This was almost a decade ago now, and working with it felt tedious. I also made it about 6 months.
- badsectoracula 5y ago
  It sounds like you didn't know svn, because what you describe is the most basic feature of any version control system - being able to revert to any of the previously submitted versions is basically the reason VCSs exist. In addition pretty much every svn GUI frontend should have provide a single click way to check out a local copy of a previous version that you can commit if you want. Svn has some warts (shelving feels sooo half baked despite having like 3 different ways for that) but at least reverting to an older state isn't one of them.
- rectang 5y ago
  I prefer Git, I've invested a lot in learning it, and have done presos and training for it over the years. But I cut my teeth on CVS, and Subversion was a significant improvement over CVS. Not that I expect anybody to maintain historical perspective. Linus Torvalds famous 2007 rant at Google shitting all over Subversion and its developers set the tone for a long tradition of anti-Subversion anti-history. Never mind "learning from what's gone before", it's like there was only backwards progress until the tool du jour was suddenly invented ex nihilo.
- layer8 5y ago
  Not sure what you mean, as “pushing bugs without testing” (or not using bugfix/feature branches) has nothing to do whatsoever with SVN.
tigerlily 5y ago
I appreciated the historical context with RCS et al. but I’m left wondering where mercurial sits in all this? I’m curious about the differences between git and mercurial, are there benefits in choosing one over the other?
- williamscs 5y ago
  I used mercurial at one job and my experience was that the day-to-day differences were largely philosophical, especially if you primarily interact with VCS through your IDE, like me. Mercurial’s CLI API is supposedly cleaner, but I hardly interacted with it. Mercurial has immutable history, so no squashing commits, no deleting branches, at the time I was using it there was no amending commits, in fact reverting a commit doesn’t even come enabled out of the box! Some folks loved it; no changing history, everything documented as it happened. We practiced trunk based development, so no branches except for hotfixes, so there wasn’t a lot of sprawl. Ecosystems largely don’t support mercurial, so that’s definitely a consideration. Since Merge Requests and feature branches are largely practiced now, I feel like there’d be a lot of noise in a repo if folks used mercurial. I don’t particularly miss mercurial, personally. I’m less into “pure” workflows and forcing behaviors. I think git is super flexible and generally practical and I’m overall pretty happy with it.
  - howinteresting 5y ago
    Basically none of this post is true. History in Mercurial is thoughtfully mutable (much more than Git) with public and draft phases; hg backout is part of the base distribution; it fully supports the PR model and better ones like stacked diffs. Ultimately it lost because of GitHub, but it lives on as Fig at Google and Eden at Facebook (both of which heavily use mutable history, of course).
    - Miiko 5y ago
      It is kind of true, though. From Mercurial docs: >The public phase holds changesets that have been exchanged publicly. Changesets in the public phase are expected to remain in your repository history and are said to be _immutable_ Note that in Git all history is mutable, even if published. Regarding 'backout' (and 'revert'), to the best of my knowledge, it does not revert commit, it creates a new one (reverting changes), and I frankly do not know is that's possible at all to amend commit in Mercurial (when I worked with it, that was definitely not possilbe, but that was a long time ago)
nemetroid 5y ago
> The basic logical unit of Git is the commit, which is a set of changes to multiple files. In some circumstances it's helpful to think of commits as sets of changes, but Git's commit are snapshots and not changesets. Converting commits into sets of changes is done on-demand.
- rectang 5y ago
  That's true until you get back to Git's packfiles, which use deltas. Git's form of compression is very interesting, but a key concept as you study the history of version control is that snapshots and deltas encode the same information, so the choice of which to use is an implementation detail[1]. [1] I covered this in detail in a preso on Git data structure design for Papers We Love San Diego: https://www.youtube.com/watch?v=fHSZz_Mx-Uo&t=400s https://www.youtube.com/watch?v=fHSZz_Mx-Uo&t=400s
  - karatinversion 5y ago
    This is sensitive to the design of the delta format though, once you have merges. I had to write some code to migrate version history from Rational Team Concert to git. RTC has a uuid for each version of a file, and deltas are a set of zero or more predecessor versions, and a successor version. This allowed the same delta to be present in different “streams” (branches), if they only differed in files not relevant to the delta; but it becomes impossible to reconstruct a history of snapshots from the change sets.
- kaashif 5y ago
  Git's user interface is very confused in this respect. You can tag a commit with a version identifier, and that indicates commits are snapshots or versions. But then you have cherry-pick, which seems to work by "applying a commit" (you can't "apply" snapshots...I think) with git cherry-pick hash. That's the same thing as git cherry-pick hash^..hash which seems to more clearly indicate that we're applying the diff between two commits. And rebase, which really does present itself as a tool for reordering diffs. Anyway, everyone knows what you mean when you say "apply this commit" so maybe this is just a stupid complaint about "consistency" with no real point. Especially since git does use both deltas and snapshots under the hood.
bbkane 5y ago
This article covers this history of vcs, and the current standard, git, but I wish it had a section about other approaches and apps, like perforce, Google's monorepo tooling, pijul, PlasticSCM + Unity, or Facebook's Eden. All of these alternatives have reasons for existing, and I would have enjoyed reading more about them.
jeffrallen 5y ago
This article picks up the thread at SCCS, but there have to have been version control systems before that, i.e. on System 360.
- brazzy 5y ago
  SCCS was originally developed on System/370. And it was the first true version control system specifically for source code. There were some earlier programs with rudimentary similar functionality, but they're more comparable to diff/patch.
ncmncm 5y ago
> "RCS is faster and uses less disk space than SCCS." That was the promotion. In fact RCS was never as fast as SCCS. RCS did not, in fact, use less disk space than SCCS. It is hard to identify any particular where RCS was better. The code quality was abysmal. But Tichy got a PhD out of it, so there was that, anyway.
splittingTimes 5y ago
What do you do with repos that have to version control (a) source code / txt files but also (b) large quantities of binary data /resources (single digit GBs)?
- Thev00d00 5y ago
  Git LFS?
- badsectoracula 5y ago
  Personally i'm using Subversion. It has a bunch of annoyances and the GUI frontend story is poor on Linux (the best i've found -at least in openSUSE's repos- is kdesvn but it barely has seen any development in recent years and lacks support for any non-basic functionality) but it seems there hasn't been any improvement in CVCSs since Svn, at least in the open source space (which kinda makes sense since the overwhelming vast majority of developers work mainly or only with code and text files), so it is basically the best you can get.
  - adrianmsmith 5y ago
    > GUI frontend story is poor on Linux On the other hand, if you're on Windows, TortoiseSvn is one of the best VCS interfaces I've ever used. - It isn't yet another tool which shows you all your directories and files (in addition to Explorer and your IDE/editor). - As Subversion was always designed to be a library (as it was already obvious then that VCSs would be used from other tools like IDEs) the integration is much better than TortoiseCvs or TortoiseGit which compose command lines and then execute them.

90 points by ashvardanian 5y ago

My previous employer still uses svn. It created so much headaches and frustration due to unproductivity because e.g. someone pushed a bug without testing and you unknowingly downloaded it. No way to easily reverse of course. It was my first job after University and taught me that CRUD b2b Java enterprise jobs are to avoid at all costs in the future. For what it's worth though, I had some very funny-sad stories to tell when I interviewed to get out of there after just 6 months. Never tought a versioning system could burn me out. Git is standard for very obvious reasons.

cognomano 5y ago
Sincere question: what does Git have that makes easy to revert the change on your example that SVN doesn’t have? I barely know Git, that’s why I ask.
- tom_ 5y ago
  You (or anybody) can use git revert to create a new commit that undoes previous commits: https://git-scm.com/docs/git-revert https://git-scm.com/docs/git-revert Perforce has something similar too: http://ftp.perforce.com/perforce/r16.2/doc/manuals/cmdref/p4_undo.html http://ftp.perforce.com/perforce/r16.2/doc/manuals/cmdref/p4...
  - hibbelig 5y ago
    Sven also has a command for reverting a commit, ie committing the inverse of a previous commit.
    - Izkata 5y ago
      For anyone looking for it, it's not as intuitive as git. In svn, you reverse-merge the commits from the current branch's history you want to revert: svn merge -c-123 . # single commit, the second "-" is "do the merge backwards" svn merge -r123:122 . # Multiple commits in reverse order, "the change going from 123 to 122" https://stackoverflow.com/questions/13330011/how-do-i-revert-an-svn-commit https://stackoverflow.com/questions/13330011/how-do-i-revert...
- chriswarbo 5y ago
  Git makes branching and merging easier, and the whole history is available locally. You can just ignore those buggy commits and base your work on an older version; when someone eventually fixes the bug, you can merge the bug and its fix into your changes, to become up-to-date (with the possibility of conflicts, but nothing is completely free ;) ).
Supermancho 5y ago
> No way to easily reverse of course. Revert to the previous version. Push as new version. Fixed? SVN was used widely and for years, prior to git. I remember the biggest problem being expensive (full copy) branching.
- layer8 5y ago
  Creating branches is not expensive in SVN, because it’s copy-on-write (server-side). Maybe you mean switching the local working copy to a different branch?
  - Supermancho 5y ago
    > Creating branches is not expensive in SVN, because it’s copy-on-write Copy on write is an expensive operation for branching. SVN repos that are multiple gigs, in size, are a pain to create branches for.
    - layer8 5y ago
      Not sure what you mean. Copy-on-write means that no actual copy is made initially. Branching is therefore almost instant in SVN and only requires minimal storage space. Only when you modify a file within the branch (or the original) does that specific file get copied (or rather, the diff of the modification gets stored). What is slow in SVN is switching to the branch client-side, because branches are always created server-side and you still need to synch the whole contents of the branch from server to client when switching (which works similar to a regular `svn update`).
      - Supermancho 5y ago
        I'm not sure what you mean either. I don't care what SVN does now, only what it did when companies abandoned it en-masse around SVN v1.6, since that's the context of my comments.
        layer8 5y ago
vlod 5y ago
It's one of my interview questions when applying for a job. I say something along the lines: "I know this is a ridiculous question, but do you 1) use version control and 2) what version control do you use" and then explain I have to ask these questions becz of obvious reasons.
- tonyg 5y ago
  Nice. Sort of a reverse FizzBuzz.
- kevin_thibedeau 5y ago
  Do you have a monorepo? Test infrastructure?
- arthurjj 5y ago
  There's a blog post from the early 00s called The Joel Test for judging a software team. Using source control is actually the first question. Sounds like you reinvented it :) https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...
- icedchai 5y ago
  I had a job in the late 90's at a newly formed subsidiary of a multi-billion dollar corporation. The product was cobbled together from various third party software they licensed or acquired outright, and we were customizing. You would think they'd have set up version control to at least keep track of what came from where. Nope. Here I was, a 22 year old kid, teaching people about CVS. SVN wasn't quite out yet.
  - layer8 5y ago
    Same for me in the early 2000’s. :)
    - kevin_thibedeau 5y ago
      I had a coworker hired in 2015 (with previous work experience) who had never used any revision control.
kadoban 5y ago
There is good git <-> svn integration. I was using git even when any of my peers or projects were on svn and they never noticed.
icedchai 5y ago
I once took a job at a place that had migrated from git to perforce because it was the "corporate standard." Some departments worked with large binary assets (videos, sound files) where I understand it made more sense. We were developing web apps. This was almost a decade ago now, and working with it felt tedious. I also made it about 6 months.
badsectoracula 5y ago
It sounds like you didn't know svn, because what you describe is the most basic feature of any version control system - being able to revert to any of the previously submitted versions is basically the reason VCSs exist. In addition pretty much every svn GUI frontend should have provide a single click way to check out a local copy of a previous version that you can commit if you want. Svn has some warts (shelving feels sooo half baked despite having like 3 different ways for that) but at least reverting to an older state isn't one of them.
rectang 5y ago
I prefer Git, I've invested a lot in learning it, and have done presos and training for it over the years. But I cut my teeth on CVS, and Subversion was a significant improvement over CVS. Not that I expect anybody to maintain historical perspective. Linus Torvalds famous 2007 rant at Google shitting all over Subversion and its developers set the tone for a long tradition of anti-Subversion anti-history. Never mind "learning from what's gone before", it's like there was only backwards progress until the tool du jour was suddenly invented ex nihilo.
layer8 5y ago
Not sure what you mean, as “pushing bugs without testing” (or not using bugfix/feature branches) has nothing to do whatsoever with SVN.

tigerlily 5y ago

I appreciated the historical context with RCS et al. but I’m left wondering where mercurial sits in all this? I’m curious about the differences between git and mercurial, are there benefits in choosing one over the other?

williamscs 5y ago
I used mercurial at one job and my experience was that the day-to-day differences were largely philosophical, especially if you primarily interact with VCS through your IDE, like me. Mercurial’s CLI API is supposedly cleaner, but I hardly interacted with it. Mercurial has immutable history, so no squashing commits, no deleting branches, at the time I was using it there was no amending commits, in fact reverting a commit doesn’t even come enabled out of the box! Some folks loved it; no changing history, everything documented as it happened. We practiced trunk based development, so no branches except for hotfixes, so there wasn’t a lot of sprawl. Ecosystems largely don’t support mercurial, so that’s definitely a consideration. Since Merge Requests and feature branches are largely practiced now, I feel like there’d be a lot of noise in a repo if folks used mercurial. I don’t particularly miss mercurial, personally. I’m less into “pure” workflows and forcing behaviors. I think git is super flexible and generally practical and I’m overall pretty happy with it.
- howinteresting 5y ago
  Basically none of this post is true. History in Mercurial is thoughtfully mutable (much more than Git) with public and draft phases; hg backout is part of the base distribution; it fully supports the PR model and better ones like stacked diffs. Ultimately it lost because of GitHub, but it lives on as Fig at Google and Eden at Facebook (both of which heavily use mutable history, of course).
  - Miiko 5y ago
    It is kind of true, though. From Mercurial docs: >The public phase holds changesets that have been exchanged publicly. Changesets in the public phase are expected to remain in your repository history and are said to be _immutable_ Note that in Git all history is mutable, even if published. Regarding 'backout' (and 'revert'), to the best of my knowledge, it does not revert commit, it creates a new one (reverting changes), and I frankly do not know is that's possible at all to amend commit in Mercurial (when I worked with it, that was definitely not possilbe, but that was a long time ago)

nemetroid 5y ago

> The basic logical unit of Git is the commit, which is a set of changes to multiple files. In some circumstances it's helpful to think of commits as sets of changes, but Git's commit are snapshots and not changesets. Converting commits into sets of changes is done on-demand.

rectang 5y ago
That's true until you get back to Git's packfiles, which use deltas. Git's form of compression is very interesting, but a key concept as you study the history of version control is that snapshots and deltas encode the same information, so the choice of which to use is an implementation detail[1]. [1] I covered this in detail in a preso on Git data structure design for Papers We Love San Diego: https://www.youtube.com/watch?v=fHSZz_Mx-Uo&t=400s https://www.youtube.com/watch?v=fHSZz_Mx-Uo&t=400s
- karatinversion 5y ago
  This is sensitive to the design of the delta format though, once you have merges. I had to write some code to migrate version history from Rational Team Concert to git. RTC has a uuid for each version of a file, and deltas are a set of zero or more predecessor versions, and a successor version. This allowed the same delta to be present in different “streams” (branches), if they only differed in files not relevant to the delta; but it becomes impossible to reconstruct a history of snapshots from the change sets.
kaashif 5y ago
Git's user interface is very confused in this respect. You can tag a commit with a version identifier, and that indicates commits are snapshots or versions. But then you have cherry-pick, which seems to work by "applying a commit" (you can't "apply" snapshots...I think) with git cherry-pick hash. That's the same thing as git cherry-pick hash^..hash which seems to more clearly indicate that we're applying the diff between two commits. And rebase, which really does present itself as a tool for reordering diffs. Anyway, everyone knows what you mean when you say "apply this commit" so maybe this is just a stupid complaint about "consistency" with no real point. Especially since git does use both deltas and snapshots under the hood.

bbkane 5y ago

This article covers this history of vcs, and the current standard, git, but I wish it had a section about other approaches and apps, like perforce, Google's monorepo tooling, pijul, PlasticSCM + Unity, or Facebook's Eden. All of these alternatives have reasons for existing, and I would have enjoyed reading more about them.

jeffrallen 5y ago

This article picks up the thread at SCCS, but there have to have been version control systems before that, i.e. on System 360.

brazzy 5y ago
SCCS was originally developed on System/370. And it was the first true version control system specifically for source code. There were some earlier programs with rudimentary similar functionality, but they're more comparable to diff/patch.

ncmncm 5y ago

> "RCS is faster and uses less disk space than SCCS." That was the promotion. In fact RCS was never as fast as SCCS. RCS did not, in fact, use less disk space than SCCS. It is hard to identify any particular where RCS was better. The code quality was abysmal. But Tichy got a PhD out of it, so there was that, anyway.

splittingTimes 5y ago

What do you do with repos that have to version control (a) source code / txt files but also (b) large quantities of binary data /resources (single digit GBs)?

Thev00d00 5y ago
Git LFS?
badsectoracula 5y ago
Personally i'm using Subversion. It has a bunch of annoyances and the GUI frontend story is poor on Linux (the best i've found -at least in openSUSE's repos- is kdesvn but it barely has seen any development in recent years and lacks support for any non-basic functionality) but it seems there hasn't been any improvement in CVCSs since Svn, at least in the open source space (which kinda makes sense since the overwhelming vast majority of developers work mainly or only with code and text files), so it is basically the best you can get.
- adrianmsmith 5y ago
  > GUI frontend story is poor on Linux On the other hand, if you're on Windows, TortoiseSvn is one of the best VCS interfaces I've ever used. - It isn't yet another tool which shows you all your directories and files (in addition to Explorer and your IDE/editor). - As Subversion was always designed to be a library (as it was already obvious then that VCSs would be used from other tools like IDEs) the integration is much better than TortoiseCvs or TortoiseGit which compose command lines and then execute them.