Hacker News Reader

Comment by kderbe | Hacker News Reader

Quote from Tarn Adams (DF's creator):

I don’t even use version control. If you don’t know what that is then you’re not gonna yell at me. If you even know what version control is you’re gonna be like, ‘You don’t use version control? You don’t use source control? What is wrong with you? How can you even work?’

If you're the sole developer of a project and you have, say, hourly backups, then maybe version control is a waste of effort? I would still use it out of habit, but it seems perfectly reasonable to me that Tarn would choose not to.

View on HN

For me version control isn't even really about having backups (though that is a nice side effect). Version control is about documenting and annotating the process of creation, and it is uniquely necessary in programming because of how eternally iterative programming is. Code that is not annotated with its history and its motivations suffers to an extreme degree from entropy, becoming more and more difficult to understand.

VC is part of code. Not using it is, to me, like refusing to use verbs.

To me it's a way of creating checkpoints which I can revert to when I've taken a wrong turn. It actually increases productivity for me.

It's also a useful way of managing different experiments, and discarding the ones that didn't work and reverting to last known good, or integrating the ones that do work. That gets increasingly messier as your codebase grows.

I agree that version control is a fundamental part of software and if you ever have to read code I hope you have access to the versioning and issue discussions. Some people are ok without it for personal projects, but one day someone is going to read your code. Please be nice to them and give them the history behind your decisions.

Not using VC is coding with permadeath.

We play Dwarf fortress; Tarn is playing the meta game.

Version Control is not really a part of the code, but it's a part of the whole project if you will. There's code, version control, build system, issue tracker.

In some cases these can be very simple, and the simplest cases I can think of are: version control - backups, build system - batch/script file, issue tracker - text file.

Although once you know one of the more complex versions of each system then it's easier to just use that. (Git/SVN/CVS, make/CMake/Premake, etc)

well vc to me is about merging and managing integration in a sane way, the ability to rollback on snafu is surely welcome, but for my side projects I just use some cloud sync service

Then you lack the history of your code, storing only the latest version. Though for personal projects, this might not matter, it's all a part of discipline in my eyes.

If you see SCM as too time consuming, then I think you need more practise, and as such, should be using as much as you can.

There's an article with an outrageous title (claiming one's getting towards the goal of simulating existence!) and the top comment is about "he doesn't use version control?!".

That's so HN.

To be fair, the title is serious exaggeration. Tom Adams has a large task list of implementation ideas, and they're 42% complete. He then says that these represent the "narratively interesting" parts of existence.

If I made a game that had a day and night, sleep and awake, food, drink, sex and death, I could claim that it simulates 100% of the interesting parts of existence. To cast that as actually simulating existence would be silly, though.

Lisa, I want to play your game.

Where does it talk about simulating existence? I tried skimming it

I read the whole thing and I didn't catch that part either.

What?

The entire article is about this.

It would be hard to find a paragraph where this isn't explicitly mentioned.

You didn't skim very well.

I don't think it would be a waste of effort. Unless he's got an amazing mind, uncanny ability not to make mistakes, and doesn't forget anything, getting `$vc blame ...` is worth it on its own. I'd argue it's not reasonable, but it's his choice to make.

But I really hope he's got automatic, offsite backups going.

Not sure if he will ever read this thread, but FWIW, free rsync.net account for life, if he wants one.

Same goes for Terry A. Davis.

This is the same exact argument against buying renter's insurance (for instance).

Lot's of programmers are creatures of habit. It probably is faster for him to work without version control. Until that one day when it isn't and he wishes he was.

It's the next level on from "I don't need comments, I can remember everything" and "meaningful variable names take too long to type"

> This is the same exact argument against buying renter's insurance...

Eh? I don't buy RI because

* I can cover the replacement cost of everything covered by pretty much every RI policy I've ever seen

* Over the decades I've been living on my own, I've never had a situation where any RI policy would kick in

Therefore, RI policies are nothing but money set ablaze for me. I'd rather make use of that money.

Can you cover the cost of everything at once? If that's the case, good for you, but I pay for insurance to cover those one in a million chances like the house burning down with everything in it. It's entirely possible I'll never claim, but if my house just burnt down I don't want to be worrying about where I'm going to find money for a hotel tonight, and replacing everything I own tomorrow.

Renters insurance isn't just about replacing your belongs, it also is about liability coverage (e.g. someone is injured in your apartment.)

Insurance is state by state. And the $10K I had on my apartment before I dropped it wouldn't pay for a paper cut in the ER anyway. At least it was extremely cheap like $10/yr as some kind of package deal with my car insurance. That was for a masonry and steel and tile apartment building, likely a wood house would be much more expensive.

> Can you cover the cost of everything at once?

Yes. That's why I said that I could cover the replacement cost of everything. :)

My real loss would be the data that doesn't have offsite backups. I'm unaware of any RI policy that will cover highly-competent data recovery services. (And if one exists, I expect that it will be outrageously expensive.)

A good test may be how long you have to be saving the insurance payments to cover everything.

My apartment complex requires proof of renter's insurance above 300k for me to even live here. I've nearly gotten in trouble a couple of times when the old proof reached its expiration and I neglected to show them the updated documents.

An overflow from a bathtub on the 9th floor can cause ~40k of damages in under an hour.

Renters caps at 300k and they added that cap becuase you can easily reach that level of damage. Still it's 10$ a month so the odds of that happening are rather low.

> Over the decades I've been living on my own, I've never had a situation where any RI policy would kick in

That's fairly expected. Given my current RI cost and how much it covers, they're losing money if I make a significant claim more than every 200 years or so.

Version control is a really cheap and really useful time machine with notes for all the periods of a program's life that people want to either travel to or just see. It's really useful whether or not you work in a team. It's also so trivial to set up and use now with git and mercurial, that it makes me scratch my head whenever experienced programmers mention that they don't use it.

It's about documenting when and where changes are made so that you can find bugs easier, not for backups.

Agreed. Others have pointed out that one can just commit daily and use git as a backup.

This is true, but there is still a psychological difference: We have become slaves of our window managers and development tools. The fewer tools you use, the more true creativity is unleashed.

The best works of humanity have been written before the existence of version control (and computers for that matter).

I see version control as a necessary evil for multi-developer projects.

Well, if you're developing something, and that isn't your development tools themselves, you are still a slave to your development tools. I really don't buy this argument, and I just think that it's a matter of habit and convenience. You can pick and choose development tools freely until you think that you have a satisfying workflow.

I would argue that for me, personally, using version control "unleashes more true creativity" because I can fire and forget my changes and just branch out or roll back until I find something I like, without thinking too much about where and what to backup. The not actually writing code or designing aspects of development then take less time out of my work.

I have to agree. With SCM, I feel more in control, and worry less about my code and files getting lost, and feel like I am free to do anything.

I tell my developers when they're worried about testing something on code, just create a branch and try it, and if it fails, just move on. You shouldn't ever be worried about losing code, or changing things. This is one of the greatest advantages of SCM -- how many variations of a codebase you can have, and how easy that can be.

Well, you could use the same logic for comments, namespaces, variable and function names, high-level languages.

All of these are created to mitigate human errors. If you think that you don't make them, why bother? Write the whole thing in hand-crafted optimized assembly, from beginning to the end.

And some people have done just that. In fact tons of mainstream 80s programmers wrote whole games and other apps in optimized assembly from beginning to end. And some still do (MenuetOS, TempleOS, etc).

But obviously, that's a slippery slope. You can do anything in between.

The other end of that BS argument line is that you could use the same logic to depend on ALL available tools -- and refuse to write anything without an IDE, package manager, language features like contract programming, formal proofs, etc.

Sounds like TA is asking for some Fun!

Oh I hope he has good offsite backups at least. I would hate for the world to lose the future of Dwarf Fortress because he loses his code.

No, version control is still advantageous if the project has more than, say, 5000 lines (or however many lines you are still able to fully comprehend as a whole).

- If you're using services like github or bitbucket, you have remote backups of your source in case your HDD breaks.

- You have clear documentation of your progress, the changes, what you implemented when.

- You can always revert to a prior point. If you try to implement a risky feature that might break a lot of things, and if it does, you can revert to an old version with 1 command. If you have hourly backups, or folders with regular full backups, you will scramble to find the right version to revert to (I happen to know from experience!)

- If you take a break from the project, you can quickly pick up from where you left off when you read your last commit message.

Trust me, once you started using VC on solo projects, you can't imagine your life without that convenience. It's so easy to set up and just makes your life easier in many ways.

Popular version control takes natural, insignificant, almost unconscious modifications and turns each into an explicit diff that must be entered into the system and documented forever. If you are a solo developer, version control is literally a waste of time. Just write the damn code and back up it at the end of the day. Leave meticulous documentation to the uberprojects, megacorps, and CS grads that want to pretend that they are doing something meaningful.

I disagree. Version control very much impacts the process of writing code. For example, if I'm going to make a major change to a solo project but I don't know what angle to approach it from, I'll create a branch to test one approach and another to test a different approach. If I'm unhappy, I can always branch from master again. The alternative would be to either attempt to make as few breaking changes as possible or test out exactly one at a time and lose progress when I go from one approach to another. Also, if I need to go back to an older version to fix something broken or remove a part of my code, commit messages document the changes so that I don't have to think of the code as a linear timeline of changes and search for the date, but rather search for commits that include keywords in the names and focus on those.

You can do much of what you described by copying directories around, keeping a text file running sheet and judicious use of winmerge. The key thing is to be managing complexity. git provides good mechanisms for this but it is not the only way. Linus didn't use version control for at least a decade, either. git started out as an automation of an existing manual process he had.

> You can do much of what you described by copying directories around, keeping a text file running sheet and judicious use of winmerge.

Sorry, but can I just check, are you saying this is the alternative as in you SHOULD do this, or are you saying this is the alternative as in you SHOULD NOT do this?

It's just the way you wrote it sounds like you're saying this is the recommended way of developing, which I'm sure is not what you meant.

Also, is winmerge available in .deb/.rpm?

Winmerge is Windows only. I imagine this means this strategy can't be followed at all unless you use Windows? ;)

The approach is an alternative, as in: you can do it. I used to work that way before I used version control, and I know I'm not the only one. I definitely prefer the workflow with version control, that's for sure, but some seem not to find it especially compelling when working alone and that is their prerogative.

When you're working on your own, any process is fine, if you are comfortable with it. The object of the exercise is to create useful/interesting/etc. products for people to use/enjoy/etc. - and you'd have a hard time arguing that this is a goal Dwarf Fortress has failed to meet.

(Unsurprisingly, I've yet to meet anybody that's preferred working without source control on shared code. But perhaps they do exist.)

Your post is passive-aggressive from start to end. If you state questions respectfully I'll have a shot at a response.

This is still version control, just without very many features and easy to mess up.

> If you are a solo developer, version control is literally a waste of time.

Strong disagree. If you're working on things that are sufficiently complex, you'll not-infrequently find yourself in a situation where the thing you were working on has become broken, and you can't remember how or when it broke.

Single-dev version control lets you make frequent checkpoints so that you can compare the current state to a previous one to discover the source of and quickly recover from failures of the mind such as these.

My git history is littered with one or three word commit messages. If I ever go to publish my code (or finish with what I was doing) then I rebase all that shit into a coherent history. But, until that point I don't spend even a microsecond worrying about attaching meaningful messages to my checkpoint commits.

Eh...I find git is actually really bad for this type of thing. It's too in the way. Git is great for "I'm throwing all this out, but want to remember what I did or some of the neat things in it".

But to fix an accident? That's what ~5-min ZFS snapshots are for.

How are ~5 minute ZFS snapshots significantly better than

  git log --patch

to look at your history, combined with

  git checkout $COMMIT

to get the code to perform any tests required? (Or, if you have a reliable automated test,

  git bisect start HEAD $KNOWN_GOOD_COMMIT -- && git bisect run $TEST

will automatically find the error for you.) [0][1]

And remember that the git checkpoint creation process is -at its most verbose- running

  git commit -m "C"

[0] You can use points-in-time as commit references, like 'master@{30 minutes ago}' or 'HEAD@{2016-01-01}'

[1] And even if you don't have a test, you can easily manually run the bisect machinery.

That sounds like a pretty nifty feature - can you point at any docs about how that works/how to set it up?

At university the lab systems had a networked home directory setup, and one of the greatest things was a '/yesterday/' link to your personal homedir, exactly as it was 1 day ago.

I have no idea how they set it up, but something along these lines is plausible.

Even on a solo project, `git bisect` by itself is more than enough reason for me to use source control. I could script something similar that ran against my daily backups, but then I'd have to recursively diff two backups to find out what had changed between them - at which point I'm basically implementing a shoddy subset of what git already does.

My 'backups' may as well be a cronned:

  git add . && git commit -m "Daily snapshot" && git push

Ta-da! You are now 'using' source control.

This or any other automatic backup solution has a big problem though: if the backup happens while you have a syntax error or something in your code then your test suite will fail and any bisect type functionality you have will be useless.

Using version control like git kinda forces you to change the way you are developing. You start to think more about building logical pieces and also really think about how the software is coming along.

I would recommend learning git for anyone. Sure, it's a big hassle, because it forces you to rethink your habits. But in the end, learning it has done me nothing but good and using it enforces me to follow good practice at the same time.

Also, just the support of 'git stash' to throw away experiments that didn't work easily is worth it. Tagging versions for release, demos, whatever .. git can help there too.

> Using version control like git kinda forces you to change the way you are developing.

It doesn't. Nothing prevents you from adding/committing several days worth of work with a "changed stuff. fixed some other stuff" commit message.

Ok, using SCM like git _allows_ you to change the way you are developing. You will still need to use the tool correctly.

If people have good reasons for not doing certain things, then fine, but when people are just averse to it because they're lazy, well, that irks me (when I have to deal with them.)

Very true. I knew a lead developer once that with the majority of his commits to TFS would give it some variation on the commit "latest and greatest" (If he didn't want to type that it might be "l&g").

I didn't speak up about it because I was only a contractor at the time, but it made me wince to see a whole history list of his commits with like 20 "latest and greatest" and maybe three commits that actually said what he did.

But most places I've been to, people have been pretty good about explaining what they've committed, when version control was being used.

I use this in an alias:

git log --pretty=oneline --abbrev-commit --graph --stat

Seeing the names of the changed files in each commit gives me a lot more of context than simply the commit description.

And I could double-click any commit and get the 'changeset details' with all the files modified and their diffs, but it's still better to provide an overview of what you're checking in instead of forcing people to interpret your code.

At my current job we have dev tasks associated with the changesets (if applicable), so that helps provide context also.

> If you are a solo developer, version control is literally a waste of time.

If and only if you're a solo developer working on a single computer and work on a pretty linear, one feature at a time development.

And if you're a solo dev, you won't need to "waste" a lot of time in version control anyway. All you need is "git init", "git add" and "git commit" and you're already better off than without. Anything on top of that is optional but useful.

You make it sound a lot harder than it is.

What it is:

  git commit -am '(what changed)'

Effortless combination of history, backup, and publishing. There’s very little reason not to do it. Up to preference how often it’s done and how detailed messages are.

Git branches have changed the way I code. Even if I didn't have to maintain stable and development branches of my apps the other benefits are well worth the very small overhead of managing code in Git.

And of course with even one other developer working on the same code base I'd say VC is practically mandatory.

> Just write the damn code and back up it at the end of the day.

If you save a copy of your code each day, you are using version control - just an ad-hoc, error-prone sort of version control that wastes space and makes it painful to do any of the things people use version control for.

You can use version control as a domain-specific backup tool. I think it's irrational to not use it if unless you're writing some quick toy code.

Although I would not subscribe to the idea that VC as a solo developer is always a waste of time, there are definitely small scope projects where I do not use it.

If you know your project is for sure _personal_ (i.e. not shared) and a small _proof-of-concept_ (i.e. if you go further in that direction you will do a rewrite anyway), I think it is overkill. Your code and data will be in so much flux, that good old copying is faster than dealing with the VC.

Thinking about it, I think it makes sense to add VC to a project, when it delivers its first satisfying result, I would call that the proof-of-concept program. At that point you throw it away/archive it, or you have bigger plans, then you probably add version control knowing you have this working prototype and rewriting stuff.

You do not have the history to that point, but it would not be helpful anyway.

There's nothing 'forever' about this. If you don't like all that cruft in your version control, you can always just start a new 'clean slate' repo. And you don't have to document anything. And it literally takes 2 seconds to commit and push your code from the command line.

You waste more time picking your nose.

You are confusing old school CVS and SVN version control with the modern, branch oriented workflow that can be achieved with Git or Mercurial.

Easy branching and merging enable exploratory programming in a way that makes you stop worrying about a whole class of regression bugs forever.

You could just have really short or even empty commit descriptions, if that's your worry.

Reply on news.ycombinator.com