4 ms·

The thing that really scares me is that he doesn't use version control. I hope and assume that he has SOME kind of backup approach, but the thought of trying to

The thing that really scares me is that he doesn't use version control. I hope and assume that he has SOME kind of backup approach, but the thought of trying to wrangle that many lines of code without proper VCS, in what is clearly an insanely complex codebase, is just beyond me.

db48x 11y ago
Version control is a must when you're working with other people. When you're the only one writing code it's not so important.
- wingerlang 11y ago
  That's debatable. Version control have helped me a lot. It also helps me experiment with new code without risking forgetting something because I can always roll back.
  - dalke 11y ago
    I agree that the topic is debatable. A few years ago I looked for any studies on the usefulness of a version control system over, say, a versioning filesystem. (Examples of such include the VAX filesystem which auto-versioned every save, Dropbox does the same for at least 30 days, and the Mac Time Machine gives access to previous backup snapshots.) I wondered if for some projects auto-versioning on save or clock event in a VFS would be more useful than manual versioning with a VCS. For an common scenario, co-authors working on a paper might have a shared Dropbox directory. They can modify the images, Word document, etc. safely without risking forgetting something because there's the option to see older versions of the directory. Those studies have not been done. I know for myself, for the initial stages of a project, I find it more effective to iterate through multiple directories (eg, "foo", "foo2", "foo3") so I can easily compare different approaches, than to create a new repo, name the branches, and check out each one to get the same effect. I also have hourly backups, so I won't loose much in the way of code.
    - jon-wood 11y ago
      At least for me version control maps better to how I think about my code than individually versioned files at the OS level. It's very rare that a change will hit only one file, at the least it's likely to imply changes in the test suite as well, and likely there'll be several objects collaborating. Being able to group those changes together and then annotate them with a commit message is hugely useful to me for a couple of reasons. Firstly I can roll that change set back as a single unit, but more usefully I can look at the history of a given file, of even a given line of code, and then map the changes to the wider context that influenced them. I couldn't tell you how many times I've wondered just why a line is doing something, run git blame, and instantly been given an answer by a past version of me who still has all the details fresh in their head.
      - dalke 11y ago
        Oh, certainly. My comments is to highlight that there's no research that helps identify if these personal beliefs are generally true. Perhaps it's only useful for large (>1M LOC) projects, or 40% of programmers. Perhaps it's worse for spike projects with 1-3 people, <1KLOC, and <1 week of development, as compared to auto-backups of a project directory every 10 minutes and/or vim's "go back in time" history tracking. We don't really know, beyond personal experience, which is why this is very debatable.
        dilap 11y ago
        I programmed for a long time (middle school to the end of college) on 1 person or 2 person projects without version control. I'd just manually copy the directory when I'd made significant progress, or wanted to experiment with a different approach. Multi-person collaboration happened by working out who would work on what ahead of time and manually merging the bits back together. It worked great, and even though I now use git for even personal projects, I'm not sure it's on balance useful, along the lines of your thinking. Because: VC warps your thinking. You change your work habits and spend time crafting this artifact, the VC commit history, which is secondary to your actual goal. For example, there's a tendency to quickly jump between different areas, or make unrelated changes, because that works against the nice 'commit-per-thing' history that looks nice in VC. So no VC doesn't seem so crazy to me :)
  - Cthulhu_ 11y ago
    If you're the sole developer, copying code to some scrapbook or something works just as well. Probably even better, because you can create a simpler or more comprehensible archival system. And search.
    - wingerlang 11y ago
      I don't follow how it would work better. Right now I don't need to do any kind of setup or thinking. I could rewrite a huge chunk right now as an experiment and change 1000s of lines of code. Then if I don't like it I can just press "reset" and I'm back to stable. In fact, I did just that yesterday.
- incepted 11y ago
  Branches and being able to revisit older code are very important, regardless of the number of people working on the code base.
  - mattmanser 11y ago
    Branches aren't important. If you ever used pre-git, they were a massive PITA that small teams wouldn't bother with. And being able to visit old code? I can't remember a single instance in my career where that was important. I can imagine scenarios where it might be, but they've never happened in real life. The other thing I realised is that most source control systems are useless if you change a file's name, you can get to the old file, but you simply can't be bothered. So it's actually easy to effectively 'lose' old code through refactors. Source control is great for looking up the 'why' of what you did 6 months later and for backups.
    - cturner 11y ago
      And for identifying who broke the build :)
      - marcosdumay 11y ago
        On a single developer project? No need for git, it was me. The stupid guy that wrote this ugly code was me too. I still use a VCS, if only for synchronizing code between computers, and for actually erasing dead code without regrets.
        mattmanser 11y ago
        Oh, yeah, multiple computer synch is the other reason I use too, and auto-builds.
    - Shorel 11y ago
      The fact the CVS or SVN were not capable tools to use branches doesn't mean anything about modern use of branches in Git or Hg. Otherwise we would be judging all programming languages by the use cases and the pitfalls of COBOL.
shoghicp 11y ago
I met Tarn at GDC, and his answer to not using version control was using a backup of the source code in labeled CDs
- e12e 11y ago
  So he's using version control, just pretty poor and manual version control. I have a hard time seeing myself preferring to use "labelled CDs" over Merurial with an off-site copy or two -- but just because a system doesn't mostly consist of (automated) software, doesn't mean it's not a system. It's not as if Mercurial/git (in most setups) works without manual intervention (git commit) -- and arguably having automatic snapshots is worse than having manual commits (eg: if I was more diligent making use of etckeeper for my laptop, it'd contain much more useful information than the now mostly "automatic commit before apt-get upgrade". But at least it gives me some automated rollback options when I forget what I was doing with a certain daemon config or tweaking xorg manually).

db48x 11y ago

Version control is a must when you're working with other people. When you're the only one writing code it's not so important.

wingerlang 11y ago
That's debatable. Version control have helped me a lot. It also helps me experiment with new code without risking forgetting something because I can always roll back.
- dalke 11y ago
  I agree that the topic is debatable. A few years ago I looked for any studies on the usefulness of a version control system over, say, a versioning filesystem. (Examples of such include the VAX filesystem which auto-versioned every save, Dropbox does the same for at least 30 days, and the Mac Time Machine gives access to previous backup snapshots.) I wondered if for some projects auto-versioning on save or clock event in a VFS would be more useful than manual versioning with a VCS. For an common scenario, co-authors working on a paper might have a shared Dropbox directory. They can modify the images, Word document, etc. safely without risking forgetting something because there's the option to see older versions of the directory. Those studies have not been done. I know for myself, for the initial stages of a project, I find it more effective to iterate through multiple directories (eg, "foo", "foo2", "foo3") so I can easily compare different approaches, than to create a new repo, name the branches, and check out each one to get the same effect. I also have hourly backups, so I won't loose much in the way of code.
  - jon-wood 11y ago
    At least for me version control maps better to how I think about my code than individually versioned files at the OS level. It's very rare that a change will hit only one file, at the least it's likely to imply changes in the test suite as well, and likely there'll be several objects collaborating. Being able to group those changes together and then annotate them with a commit message is hugely useful to me for a couple of reasons. Firstly I can roll that change set back as a single unit, but more usefully I can look at the history of a given file, of even a given line of code, and then map the changes to the wider context that influenced them. I couldn't tell you how many times I've wondered just why a line is doing something, run git blame, and instantly been given an answer by a past version of me who still has all the details fresh in their head.
    - dalke 11y ago
      Oh, certainly. My comments is to highlight that there's no research that helps identify if these personal beliefs are generally true. Perhaps it's only useful for large (>1M LOC) projects, or 40% of programmers. Perhaps it's worse for spike projects with 1-3 people, <1KLOC, and <1 week of development, as compared to auto-backups of a project directory every 10 minutes and/or vim's "go back in time" history tracking. We don't really know, beyond personal experience, which is why this is very debatable.
      - dilap 11y ago
        I programmed for a long time (middle school to the end of college) on 1 person or 2 person projects without version control. I'd just manually copy the directory when I'd made significant progress, or wanted to experiment with a different approach. Multi-person collaboration happened by working out who would work on what ahead of time and manually merging the bits back together. It worked great, and even though I now use git for even personal projects, I'm not sure it's on balance useful, along the lines of your thinking. Because: VC warps your thinking. You change your work habits and spend time crafting this artifact, the VC commit history, which is secondary to your actual goal. For example, there's a tendency to quickly jump between different areas, or make unrelated changes, because that works against the nice 'commit-per-thing' history that looks nice in VC. So no VC doesn't seem so crazy to me :)
- Cthulhu_ 11y ago
  If you're the sole developer, copying code to some scrapbook or something works just as well. Probably even better, because you can create a simpler or more comprehensible archival system. And search.
  - wingerlang 11y ago
    I don't follow how it would work better. Right now I don't need to do any kind of setup or thinking. I could rewrite a huge chunk right now as an experiment and change 1000s of lines of code. Then if I don't like it I can just press "reset" and I'm back to stable. In fact, I did just that yesterday.
incepted 11y ago
Branches and being able to revisit older code are very important, regardless of the number of people working on the code base.
- mattmanser 11y ago
  Branches aren't important. If you ever used pre-git, they were a massive PITA that small teams wouldn't bother with. And being able to visit old code? I can't remember a single instance in my career where that was important. I can imagine scenarios where it might be, but they've never happened in real life. The other thing I realised is that most source control systems are useless if you change a file's name, you can get to the old file, but you simply can't be bothered. So it's actually easy to effectively 'lose' old code through refactors. Source control is great for looking up the 'why' of what you did 6 months later and for backups.
  - cturner 11y ago
    And for identifying who broke the build :)
    - marcosdumay 11y ago
      On a single developer project? No need for git, it was me. The stupid guy that wrote this ugly code was me too. I still use a VCS, if only for synchronizing code between computers, and for actually erasing dead code without regrets.
      - mattmanser 11y ago
        Oh, yeah, multiple computer synch is the other reason I use too, and auto-builds.
  - Shorel 11y ago
    The fact the CVS or SVN were not capable tools to use branches doesn't mean anything about modern use of branches in Git or Hg. Otherwise we would be judging all programming languages by the use cases and the pitfalls of COBOL.

shoghicp 11y ago

I met Tarn at GDC, and his answer to not using version control was using a backup of the source code in labeled CDs

e12e 11y ago
So he's using version control, just pretty poor and manual version control. I have a hard time seeing myself preferring to use "labelled CDs" over Merurial with an off-site copy or two -- but just because a system doesn't mostly consist of (automated) software, doesn't mean it's not a system. It's not as if Mercurial/git (in most setups) works without manual intervention (git commit) -- and arguably having automatic snapshots is worse than having manual commits (eg: if I was more diligent making use of etckeeper for my laptop, it'd contain much more useful information than the now mostly "automatic commit before apt-get upgrade". But at least it gives me some automated rollback options when I forget what I was doing with a certain daemon config or tweaking xorg manually).