7 ms·

Popular version control takes natural, insignificant, almost unconscious modifications and turns each into an explicit diff that must be entered into the system

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.

nv-vn 11y ago
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.
- cturner 11y ago
  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.
  - imdsm 11y ago
    > 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?
    - cturner 11y ago
      Your post is passive-aggressive from start to end. If you state questions respectfully I'll have a shot at a response.
    - to3m 11y ago
      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.)
  - jmilloy 11y ago
    This is still version control, just without very many features and easy to mess up.
simoncion 11y ago
> 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.
- XorNot 11y ago
  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.
  - shabble 11y ago
    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.
  - simoncion 11y ago
    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.
okasaki 11y ago
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.
cageface 11y ago
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.
exDM69 11y ago
> 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.
inDigiNeous 11y ago
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.
- the8472 11y ago
  > 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.
  - imdsm 11y ago
    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.)
  - cableshaft 11y ago
    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.
    - Shorel 11y ago
      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.
minitech 11y ago
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.
TomNomNom 11y ago
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.
Retra 11y ago
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.
fenomas 11y ago
> 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.
picozeta 11y ago
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.
wlievens 11y ago
You could just have really short or even empty commit descriptions, if that's your worry.
Shorel 11y ago
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.

nv-vn 11y ago

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.

cturner 11y ago
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.
- imdsm 11y ago
  > 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?
  - cturner 11y ago
    Your post is passive-aggressive from start to end. If you state questions respectfully I'll have a shot at a response.
  - to3m 11y ago
    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.)
- jmilloy 11y ago
  This is still version control, just without very many features and easy to mess up.

simoncion 11y ago

> 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.

XorNot 11y ago
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.
- shabble 11y ago
  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.
- simoncion 11y ago
  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.

okasaki 11y ago

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.

cageface 11y ago

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.

exDM69 11y ago

> 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.

inDigiNeous 11y ago

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.

the8472 11y ago
> 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.
- imdsm 11y ago
  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.)
- cableshaft 11y ago
  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.
  - Shorel 11y ago
    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.

minitech 11y ago

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.

TomNomNom 11y ago

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.

Retra 11y ago

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.

fenomas 11y ago

> 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.

picozeta 11y ago

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.

wlievens 11y ago

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

Shorel 11y ago

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.