4 ms·

I disagree. VCS use in an early stage of a project can lead to less elegant and coherent systems, because you treat everything as a series of patches from day 1

I disagree. VCS use in an early stage of a project can lead to less elegant and coherent systems, because you treat everything as a series of patches from day 1. The greatest works of humanity were written without a VCS (novels, operas). Using a VCS is only mandatory for multi-person projects.

swsieber 10y ago
I'd say then - don't consciously worry about it. But it'd be great to set something up that auto-commits your code every X minutes or X character changes.
retro64 10y ago
The greatest works of humanity were written without a VCS (novels, operas). Using a VCS is only mandatory for multi-person projects. Code is different. There are many times that I have been developing and I do something to my code that causes mystery behavior, and I don't catch it until perhaps days later. Being able to walk backward in time and see when the problem first occurred is invaluable. I used to really like using Visual Source Safe. It was so easy to set up and integrated directly with Visual Studio, there was no excuse not to have a VCS. Too bad it had a reputation for garbling itself (something I never had happen as a single dev).
- hdctambien 10y ago
  When you are teaching students how to code everything they do causes mystery behavior to them.
  - jschwartzi 10y ago
    This is true, but being able to ask the computer what changed is much more powerful than trying to remember what you did last night and how that's different from the version you had yesterday morning.
    - hdctambien 10y ago
      Being able to write code that does something in the first place is the most important. Having to learn a VCS at the same time you are learning the difference between a parameter and an argument will cause more harm than good for a novice.
      - flukus 10y ago
        On the other hand, being free to experiment, screw up and revert back quickly is great for someone just learning. I wouldn't recommend it to someone at the hello world level, but would not long after. The industry is plagued by people that don't know how to use source control.
MaulingMonkey 10y ago
> because you treat everything as a series of patches from day 1. That's an option, but not the only option. For big shared mature projects, I treat each commit (to shared branches at least) as a presentation, where I try to describe exactly what changed, how, why, and to preemptively answer any questions I suspect will come up in the code review, clean up unnecessary or unrelated changes, cross linked to any task tracking items and bugs, the code review itself, any docs I might've updated in tandem, .... the description will often be longer than the actual code changes. With a quick summary to start, so you won't typically need to read the rest, of course. After the review and submit, I'll ping QA with some stuff I think might be worth testing once the build goes green. My commit messages, at least, tend to be better than any of my coworkers. For solo seed projects, on the other hand, I take 5 seconds to try and describe what it was I did in the past X minutes. I try to remember to commit often enough that this doesn't devolve into "Changed stuff" because I forgot to commit for a day and touched 20 different things, but it happens - making those commits worse than any my coworkers generate, but still better than no VCS. They come in handy for tracking down bugs and such. > The greatest works of humanity were written without a VCS (novels, operas). Using a VCS is only mandatory for multi-person projects. Most of these had drafts and earlier revisions (or versions.) I agree that VCS is not mandatory mandatory, but the entire reason I switched to git (from SVN) was that "git init" is super low friction for getting new projects under VCS. That it handles branches way better and enables distributed workflows are mere side benefits.
wvenable 10y ago
VCS is an editing tool (in the sense of literary works). I can safely delete entire files, change the code base in crazy ways, etc -- all the things you do in an early stage project -- without worrying I might lose something. I don't even understand "treat everything as a series of patches" as that's not really a VCS workflow unless you are Linus.
clifanatic 10y ago
I disagree with your disagreement. I always use version control on everything I work on. I don't think I've _ever_ rolled back to a previous version, nor have I ever even looked at the history of something that I worked on alone. However, knowing that I _can_ has made me a lot less cautious about changing something that's "already working", and that's a good thing.
oldmanjay 10y ago
I believe the greatest works humanity has ever written are the massive software suites that enable our amazing technological civilization, so you are wrong.
vacri 10y ago
> The greatest works of humanity were written without a VCS (novels, operas) Not true. These things usually go through many drafts and revisions, and the previous drafts are usually available to check out.

swsieber 10y ago

I'd say then - don't consciously worry about it. But it'd be great to set something up that auto-commits your code every X minutes or X character changes.

retro64 10y ago

The greatest works of humanity were written without a VCS (novels, operas). Using a VCS is only mandatory for multi-person projects. Code is different. There are many times that I have been developing and I do something to my code that causes mystery behavior, and I don't catch it until perhaps days later. Being able to walk backward in time and see when the problem first occurred is invaluable. I used to really like using Visual Source Safe. It was so easy to set up and integrated directly with Visual Studio, there was no excuse not to have a VCS. Too bad it had a reputation for garbling itself (something I never had happen as a single dev).

hdctambien 10y ago
When you are teaching students how to code everything they do causes mystery behavior to them.
- jschwartzi 10y ago
  This is true, but being able to ask the computer what changed is much more powerful than trying to remember what you did last night and how that's different from the version you had yesterday morning.
  - hdctambien 10y ago
    Being able to write code that does something in the first place is the most important. Having to learn a VCS at the same time you are learning the difference between a parameter and an argument will cause more harm than good for a novice.
    - flukus 10y ago
      On the other hand, being free to experiment, screw up and revert back quickly is great for someone just learning. I wouldn't recommend it to someone at the hello world level, but would not long after. The industry is plagued by people that don't know how to use source control.

MaulingMonkey 10y ago

> because you treat everything as a series of patches from day 1. That's an option, but not the only option. For big shared mature projects, I treat each commit (to shared branches at least) as a presentation, where I try to describe exactly what changed, how, why, and to preemptively answer any questions I suspect will come up in the code review, clean up unnecessary or unrelated changes, cross linked to any task tracking items and bugs, the code review itself, any docs I might've updated in tandem, .... the description will often be longer than the actual code changes. With a quick summary to start, so you won't typically need to read the rest, of course. After the review and submit, I'll ping QA with some stuff I think might be worth testing once the build goes green. My commit messages, at least, tend to be better than any of my coworkers. For solo seed projects, on the other hand, I take 5 seconds to try and describe what it was I did in the past X minutes. I try to remember to commit often enough that this doesn't devolve into "Changed stuff" because I forgot to commit for a day and touched 20 different things, but it happens - making those commits worse than any my coworkers generate, but still better than no VCS. They come in handy for tracking down bugs and such. > The greatest works of humanity were written without a VCS (novels, operas). Using a VCS is only mandatory for multi-person projects. Most of these had drafts and earlier revisions (or versions.) I agree that VCS is not mandatory mandatory, but the entire reason I switched to git (from SVN) was that "git init" is super low friction for getting new projects under VCS. That it handles branches way better and enables distributed workflows are mere side benefits.

wvenable 10y ago

VCS is an editing tool (in the sense of literary works). I can safely delete entire files, change the code base in crazy ways, etc -- all the things you do in an early stage project -- without worrying I might lose something. I don't even understand "treat everything as a series of patches" as that's not really a VCS workflow unless you are Linus.

clifanatic 10y ago

I disagree with your disagreement. I always use version control on everything I work on. I don't think I've _ever_ rolled back to a previous version, nor have I ever even looked at the history of something that I worked on alone. However, knowing that I _can_ has made me a lot less cautious about changing something that's "already working", and that's a good thing.

oldmanjay 10y ago

I believe the greatest works humanity has ever written are the massive software suites that enable our amazing technological civilization, so you are wrong.

vacri 10y ago

> The greatest works of humanity were written without a VCS (novels, operas) Not true. These things usually go through many drafts and revisions, and the previous drafts are usually available to check out.