4 ms·

Going half a day without committing code is missing the point of version control.

by rcfox 15y ago

there 15y ago
i think the parent meant that the developer would not be able to get any more work done during that day because their machine is without a hard drive, not that the code on the hard drive would be lost.
- ErrantX 15y ago
  The better solution here is to have a couple of "gold disks" of a default developer machine; with all the required programs etc. That way if you go down you can just swap the drive out and be on your way again. This is what we do (and we have a lot of hard drive churn due to heavy use) and it works well.
  - protomyth 15y ago
    I think I would rather have the RAID so I don't have to take as much time. Setting up the personal info stuff on a machine takes time too. For Linux / Windows folks, SuperMicro has a nice tower that has 4 hot swap hard drive bays that I really like.
    - ErrantX 15y ago
      Things like Chrome and Dropbox have made this less of a chore. Speaking only for myself... I have a gold disk plus a little script that syncs scripts and configs to backups. And I use Chrome logged into my Google account. I do see your point, but a lot of it can be mitigated.
    - SoftwareMaven 15y ago
      Between BitBucket and Dropbox, it takes me no time at all (well, a little time to sync Dropbox, but I'm busy in those times).
jm4 15y ago
I think a lot of people would disagree with that statement. If you are committing that frequently then there are probably instances where you are checking in half written code that does not even compile. If you are using DVCS chances are your commits are still only stored on your local machine and just as susceptible to loss. If you are using something centralized or pushing your changes you are potentially going to disrupt the rest of the team unless you are working on a private branch. In that case, it seems as if version control is being used as a backup system where a substantial number of revisions cannot even be built. I think that is poor use of version control. It becomes difficult (at least for me) to analyze past changes (maybe months after the fact) when some of the versions are half-baked ideas that I committed for safety before going out to lunch. I think there are two requirements here: 1) redundancy of work in progress and 2) change control management. I want my work in progress to be relatively safe from failures, I want it to be automatic and I want to be able to choose which changes are worthy of their own revision number in version control. Personally, when committing work in progress I want my revisions to represent a logical stopping point and not necessarily dictated by how much time has elapsed since the last commit.
deleted 15y ago
[deleted]

Going half a day without committing code is missing the point of version control.

by rcfox 15y ago

Going half a day without committing code is missing the point of version control.

there 15y ago

i think the parent meant that the developer would not be able to get any more work done during that day because their machine is without a hard drive, not that the code on the hard drive would be lost.

ErrantX 15y ago
The better solution here is to have a couple of "gold disks" of a default developer machine; with all the required programs etc. That way if you go down you can just swap the drive out and be on your way again. This is what we do (and we have a lot of hard drive churn due to heavy use) and it works well.
- protomyth 15y ago
  I think I would rather have the RAID so I don't have to take as much time. Setting up the personal info stuff on a machine takes time too. For Linux / Windows folks, SuperMicro has a nice tower that has 4 hot swap hard drive bays that I really like.
  - ErrantX 15y ago
    Things like Chrome and Dropbox have made this less of a chore. Speaking only for myself... I have a gold disk plus a little script that syncs scripts and configs to backups. And I use Chrome logged into my Google account. I do see your point, but a lot of it can be mitigated.
  - SoftwareMaven 15y ago
    Between BitBucket and Dropbox, it takes me no time at all (well, a little time to sync Dropbox, but I'm busy in those times).

jm4 15y ago

I think a lot of people would disagree with that statement. If you are committing that frequently then there are probably instances where you are checking in half written code that does not even compile. If you are using DVCS chances are your commits are still only stored on your local machine and just as susceptible to loss. If you are using something centralized or pushing your changes you are potentially going to disrupt the rest of the team unless you are working on a private branch. In that case, it seems as if version control is being used as a backup system where a substantial number of revisions cannot even be built. I think that is poor use of version control. It becomes difficult (at least for me) to analyze past changes (maybe months after the fact) when some of the versions are half-baked ideas that I committed for safety before going out to lunch. I think there are two requirements here: 1) redundancy of work in progress and 2) change control management. I want my work in progress to be relatively safe from failures, I want it to be automatic and I want to be able to choose which changes are worthy of their own revision number in version control. Personally, when committing work in progress I want my revisions to represent a logical stopping point and not necessarily dictated by how much time has elapsed since the last commit.

deleted 15y ago

[deleted]