3 ms·

> Now on the scale of version control, you're at a zero. After I went to all the trouble to explain that my system is the best one for me? :-) What problem th

> Now on the scale of version control, you're at a zero. After I went to all the trouble to explain that my system is the best one for me? :-) What problem that I have will switching to subversion solve? Suppose I have two versions of a procedure and I can't decide whether the new version is faster and just as correct as the previous one. I keep both with #if 0 // old one #else // new one #endif And it's easy and intuitive to see them side by side and switch back and forth between them until I'm sure. The VCS just don't give me this simplicity, convenience and intuitiveness.

pgbovine 16y ago
what if you have more than 2 versions, or if your #ifdef's get nested and more hairy? slippery slope to preprocessor hell :) with git, there's a nice 'bisect' feature that lets you quickly jump back-and-forth between different versions of your code (in a binary-search-like way), so that you can debug performance issues like the one you're using #ifdefs to manually do. just check in a bunch of versions of your code and use 'git bisect' to jump between them and test each out for performance (or correctness)
- nearestneighbor 16y ago
  Realistically, you wouldn't normally have more than two versions: one "solid" and one "experimental". But if you do, there's #elif. I repeat: I see conditional compilation as a temporary thing. My code does not end up littered with them. > with git, there's a nice 'bisect' How does "bisect" know where the boundaries are? What if you change the original code a bit, like re-indent it or make another trivial change? How can you look at both versions, preferably right in the editor? What happens to time stamps when you switch between the versions? Versions cached in the IDE? Directories? (You may be surprised that Git leaves them around from previous versions) It's all doable, but not very intuitive. Why bring complexity where there is enough of it already?
  - wvenable 16y ago
    If you're say, changing an API, and then you've modified all the code that uses that API that's a large number of files with defines in them, right? Your work flow is limited to the method you've chosen not the other way around. To say it works for you sort of misses the point. Version control can free you to work in ways you can't yet imagine. > How does "bisect" know where the boundaries are? Clever algorithms. > What if you change the original code a bit, like re-indent it or make another trivial change? How can you look at both versions, preferably right in the editor? ' The file gets flagged in your editor as having a conflict. Inside the file, any code parts that cannot be merged are included the file (both versions) and you pick which one you want (or edit the changes together manually). It's actually very easy, very intuitive, and works with your editor. In most cases, you won't have conflicts. > Versions cached in the IDE? Directories? I've never had a problem with versions cached in the IDE -- probably because almost everyone uses version control it's not something that usually goes wrong. With IDE integration, it's even better. Directories are handled pretty sanely in Subversion, at least.
    - nearestneighbor 16y ago
      > If you're say, changing an API, You obviously take the snapshot before. No different from the more over-engineered approaches. >> How does "bisect" know where the boundaries are? > Clever algorithms. Really?! You change two methods in a class, and "bisect" knows how to undo only one? No, you have to spoon-feed it, "staging" your changes (I did use GitX for a day). So it's not as simple as taking snapshots after all, is it? Edit: typo, formatting
      - blasdel 16y ago
        Yes, git asks that you make your commits actually make sense, instead of "oh I'm about to leave, better check in all the unrelated shit I did today" Sounds like you'd fit in just fine with ClearCase users.
        nearestneighbor 16y ago
wvenable 16y ago
> What problem that I have will switching to subversion solve? You already have the problem (backups, multiple versions of code) you're just doing it the hard manual way. You could say the same thing about Visual Studio over Notepad -- what problem does it really solve? One is just a superior way to work. You're using stone knives and bearskins. Version control doesn't prevent you from using conditional compilation. You really wouldn't have to change your work flow at all. But you already make tarball backups -- taking the two clicks to commit your code is going to be much simpler. And if you ever screw something up, you can always go back to a working version. If you get around to branching and merging the full power of version control reveals itself. I'm currently working on a development branch of my software while the production branch continues to get bug fixes. When I'm ready to deploy, I just merge all those changes together.
- nearestneighbor 16y ago
  > 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.

pgbovine 16y ago

what if you have more than 2 versions, or if your #ifdef's get nested and more hairy? slippery slope to preprocessor hell :) with git, there's a nice 'bisect' feature that lets you quickly jump back-and-forth between different versions of your code (in a binary-search-like way), so that you can debug performance issues like the one you're using #ifdefs to manually do. just check in a bunch of versions of your code and use 'git bisect' to jump between them and test each out for performance (or correctness)

nearestneighbor 16y ago
Realistically, you wouldn't normally have more than two versions: one "solid" and one "experimental". But if you do, there's #elif. I repeat: I see conditional compilation as a temporary thing. My code does not end up littered with them. > with git, there's a nice 'bisect' How does "bisect" know where the boundaries are? What if you change the original code a bit, like re-indent it or make another trivial change? How can you look at both versions, preferably right in the editor? What happens to time stamps when you switch between the versions? Versions cached in the IDE? Directories? (You may be surprised that Git leaves them around from previous versions) It's all doable, but not very intuitive. Why bring complexity where there is enough of it already?
- wvenable 16y ago
  If you're say, changing an API, and then you've modified all the code that uses that API that's a large number of files with defines in them, right? Your work flow is limited to the method you've chosen not the other way around. To say it works for you sort of misses the point. Version control can free you to work in ways you can't yet imagine. > How does "bisect" know where the boundaries are? Clever algorithms. > What if you change the original code a bit, like re-indent it or make another trivial change? How can you look at both versions, preferably right in the editor? ' The file gets flagged in your editor as having a conflict. Inside the file, any code parts that cannot be merged are included the file (both versions) and you pick which one you want (or edit the changes together manually). It's actually very easy, very intuitive, and works with your editor. In most cases, you won't have conflicts. > Versions cached in the IDE? Directories? I've never had a problem with versions cached in the IDE -- probably because almost everyone uses version control it's not something that usually goes wrong. With IDE integration, it's even better. Directories are handled pretty sanely in Subversion, at least.
  - nearestneighbor 16y ago
    > If you're say, changing an API, You obviously take the snapshot before. No different from the more over-engineered approaches. >> How does "bisect" know where the boundaries are? > Clever algorithms. Really?! You change two methods in a class, and "bisect" knows how to undo only one? No, you have to spoon-feed it, "staging" your changes (I did use GitX for a day). So it's not as simple as taking snapshots after all, is it? Edit: typo, formatting
    - blasdel 16y ago
      Yes, git asks that you make your commits actually make sense, instead of "oh I'm about to leave, better check in all the unrelated shit I did today" Sounds like you'd fit in just fine with ClearCase users.
      - nearestneighbor 16y ago

wvenable 16y ago

> What problem that I have will switching to subversion solve? You already have the problem (backups, multiple versions of code) you're just doing it the hard manual way. You could say the same thing about Visual Studio over Notepad -- what problem does it really solve? One is just a superior way to work. You're using stone knives and bearskins. Version control doesn't prevent you from using conditional compilation. You really wouldn't have to change your work flow at all. But you already make tarball backups -- taking the two clicks to commit your code is going to be much simpler. And if you ever screw something up, you can always go back to a working version. If you get around to branching and merging the full power of version control reveals itself. I'm currently working on a development branch of my software while the production branch continues to get bug fixes. When I'm ready to deploy, I just merge all those changes together.

nearestneighbor 16y ago
> 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.