4 ms·

> But you already make tarball backups -- taking the two clicks to commit your code is going to be much simpler. And you are saying I'm not doing it right? I

> But you already make tarball backups -- taking the two clicks to commit your code is going to be much simpler. And you are saying I'm not doing it right? I have a 1-line script that does that, automatically adding time stamps to the name of the tarball. How is checking in your version simpler? > If you get around to branching and merging the full power of version control reveals itself. This attitude is unproductive, as I witness from other programmers' experience: they branch and then they branch - stuff gets inconsistent, bugs get fixed in one version, but not another, and the same bugs that were fixed before, get magically released to public 2 versions later (REAL STORY). My philosophy is MAKE BRANCHING HARD.

wvenable 16y ago
The extra click is so that you can add a description of the changes, but if you want to resist even that level of organization you could script it down to one click as well. Your system just gives you a big dumb useless tarball. For the exact same effort, you can view changes to past revisions, revert any single file to a previous version, see exactly what you changed and when. Why you wouldn't want that power for the same effort, I don't know. > This attitude is unproductive, as I witness from other programmers' experience: You said your are a solo developer so you're telling me if you had the power to branch and merge you wouldn't be able to control yourself? You'd just branch and branch and never merge and make a mess of the whole thing? Even though you could do that right now just using the file system? The whole point of tracking your changes in version control is to prevent the very thing that you describe. I simply wouldn't be able to function without that ability. Our stable production version is live and we have big changes in development (over 5 months now). Without version control the bugs fixed in production would likely never make it into the new version.
- nearestneighbor 16y ago
  > For the exact same effort, you can view changes to past revisions, revert any single file to a previous version, see exactly what you changed and when. Tarballs let you do that as well. > You said your are a solo developer Right. Those people are working on their own code base (total disaster, much of it due to branching and following the VCS "methodology". I feel like slapping their lead whenever he mentions tagging or branching. That stuff ain't free! You only have one brain! /rant)
  - wvenable 16y ago
    > Tarballs let you do that as well. No, they don't. I can right-click on any file and view all the changes as a diff, I can see exactly what I changed and when, and revert that file back to any previous version. You can't do that with a tarball -- at least not without significantly more effort. It's just better all around. > Those people are working on their own code base (total disaster, much of it due to branching and following the VCS "methodology". You're not required to use any particular methodology. I've seen people screw up with every technology in existence -- that's hardly a reason to head back into the woods and live like a cave man. There are very few things in the field of computing science that are universally agreed on. There are dozens of development methodologies, thousands of different programming languages, IDEs, etc. The closest thing we have in this business to consensus is the use of version control (even if the exact tool to use is still under debate). You're simply mistaken to assume not using version control is superior in any way to using it. There's nothing wrong with your own methods of development and backup but that isn't version control and it isn't incompatible with it either.
prog 16y ago
> I have a 1-line script that does that, automatically adding time stamps to the name of the tarball. How is checking in your version simpler? The important question is, do you have unit tests for that script :)
weavejester 16y ago
> My philosophy is MAKE BRANCHING HARD. You outline problem with branches that are long-lived, but the majority of branches created in a typical Git workflow are temporary, often lasting only a few days or less before they are absorbed into master.
FooBarWidget 16y ago
So with your system, how do you view the changes between one version and another? It's possible to view changes within a single file with diff, but what if you want to see the entire set of changes, e.g. in look for a regression? What if you're working on an experimental feature that makes your program unstable while it's still being developed, and the feature spans multiple files? If you decide later on that the feature is useless, do you modify each of those files to remove all the #ifdefs? I make a temporary branch for this and delete the branch if I decide it's a failure.

wvenable 16y ago

The extra click is so that you can add a description of the changes, but if you want to resist even that level of organization you could script it down to one click as well. Your system just gives you a big dumb useless tarball. For the exact same effort, you can view changes to past revisions, revert any single file to a previous version, see exactly what you changed and when. Why you wouldn't want that power for the same effort, I don't know. > This attitude is unproductive, as I witness from other programmers' experience: You said your are a solo developer so you're telling me if you had the power to branch and merge you wouldn't be able to control yourself? You'd just branch and branch and never merge and make a mess of the whole thing? Even though you could do that right now just using the file system? The whole point of tracking your changes in version control is to prevent the very thing that you describe. I simply wouldn't be able to function without that ability. Our stable production version is live and we have big changes in development (over 5 months now). Without version control the bugs fixed in production would likely never make it into the new version.

nearestneighbor 16y ago
> For the exact same effort, you can view changes to past revisions, revert any single file to a previous version, see exactly what you changed and when. Tarballs let you do that as well. > You said your are a solo developer Right. Those people are working on their own code base (total disaster, much of it due to branching and following the VCS "methodology". I feel like slapping their lead whenever he mentions tagging or branching. That stuff ain't free! You only have one brain! /rant)
- wvenable 16y ago
  > Tarballs let you do that as well. No, they don't. I can right-click on any file and view all the changes as a diff, I can see exactly what I changed and when, and revert that file back to any previous version. You can't do that with a tarball -- at least not without significantly more effort. It's just better all around. > Those people are working on their own code base (total disaster, much of it due to branching and following the VCS "methodology". You're not required to use any particular methodology. I've seen people screw up with every technology in existence -- that's hardly a reason to head back into the woods and live like a cave man. There are very few things in the field of computing science that are universally agreed on. There are dozens of development methodologies, thousands of different programming languages, IDEs, etc. The closest thing we have in this business to consensus is the use of version control (even if the exact tool to use is still under debate). You're simply mistaken to assume not using version control is superior in any way to using it. There's nothing wrong with your own methods of development and backup but that isn't version control and it isn't incompatible with it either.

prog 16y ago

> I have a 1-line script that does that, automatically adding time stamps to the name of the tarball. How is checking in your version simpler? The important question is, do you have unit tests for that script :)

weavejester 16y ago

> My philosophy is MAKE BRANCHING HARD. You outline problem with branches that are long-lived, but the majority of branches created in a typical Git workflow are temporary, often lasting only a few days or less before they are absorbed into master.

FooBarWidget 16y ago

So with your system, how do you view the changes between one version and another? It's possible to view changes within a single file with diff, but what if you want to see the entire set of changes, e.g. in look for a regression? What if you're working on an experimental feature that makes your program unstable while it's still being developed, and the feature spans multiple files? If you decide later on that the feature is useless, do you modify each of those files to remove all the #ifdefs? I make a temporary branch for this and delete the branch if I decide it's a failure.