6 ms·

I program solo, and for fine-grained version control, I use comments and conditional compilation, which I remove when the time comes. I also take periodic tarba

I program solo, and for fine-grained version control, I use comments and conditional compilation, which I remove when the time comes. I also take periodic tarball snapshots of my code just in case. Before you downmod me to -∞ for my uncouth approach, consider this: According to Linus, Git > tarballs > CVS > SVN (he made a statement about tarballs being better than CVS somewhere else). That leaves Git and tarballs. Now, Visual Studio is my primary development environment, and it does not integrate with Git (as far as I know), and Git just isn't well-supported on Windows (there are some fragile solutions). Secondly, I probably spent a whole day playing with Git where it's supposed to shine (OS X with GitX), and I just find it kind of awkward and unintuitive for no benefit.

solutionyogi 16y ago
I use Git on Windows with Visual Studio and I don't face any issues whatsoever. Yes, Git is not integrated with VS but I have no trouble switching to explorer and commit my changes using TortoiseGit. TortoiseGit scans my working directory and presents list of all the changes made in a session. And yes, to be on safer side, I copy and store my working directory + Git to a different location.
- nearestneighbor 16y ago
  Check out these replies: http://stackoverflow.com/questions/1500400/is-tortoisegit-ready-for-prime-time-yet http://stackoverflow.com/questions/1500400/is-tortoisegit-re... It's not just the fragility and lack of integration, but also I'm just not seeing much of a benefit to counterbalance the complexity and awkwardness.
  - solutionyogi 16y ago
    Well, I have been using it for 'production' work for last 6 months and I have not found any issues. I am not suggesting that everyone will have the same experience but I think you should give it a try before dismissing it outright based on someone else's experience. Also, if you could provide some real details on the 'complexity and awkwardness', I could share my experience which could be helpful.
    - nearestneighbor 16y ago
      > give it a try before dismissing it Giving it a try can only prove the presence of fragility, not its absence :-) Generally, people are very reluctant to criticize "hip" tools like e.g. Clojure, Haskell, Google Go, Git or its accessories. So, when 3 out of 4 people say they had problems with it, to me it weighs very heavily on the negative side.
      - wvenable 16y ago
        For the record, I agree with you on Git (on Windows at least). It's improved at a rapid pace but it's still a bit awkward. However, that's no reason to dismiss all version control.
        nearestneighbor 16y ago
        I'm glad you agree, because for the rest of the equation (Tarballs > CVS > SVN), Linus agrees with me. So you see, I embody the combined wisdom of both of you, as far as version control goes.
        wvenable 16y ago
        You have his equation wrong. He says in this article that SVN is still better than CVS. And really, I would agree that tarballs are better than CVS. So the equation is more likely SVN > Tarballs > CVS. Don't put words in Linus's mouth. Also Subversion no longer stores it's data in a database so Linus's objection in this article has been resolved. Finally, Linus's needs are pretty unique in the world. Linus isn't satisfied with Subversion for the same reasons it might work perfectly well for you.
        nearestneighbor 16y ago
        > He says in this article that SVN is still better than CVS. He says SVN is better, but is more fragile (which for source control, I interpret as being worse): SVN fixes (supposedly) those "implementation suckiness" issues. ... I think it's also a much more fragile setup and there's apparently been people who lost their entire database to corruption Even if SVN = CVS, clearly Tarballs > SVN, according to him. His actual quote was Tarballs >> CVS. I can dig it up if you can't.
Locke1689 16y ago
Git is not supposed to shine on OS X. Git was written with the Linux kernel and subsystem in mind. OS X is UNIX, but it is not Linux. Try Mercurial. Git's piss-poor cross platform support has all but removed it from my development routine. Well, that and I find Mercurial's interface far more comfortable to work with.
- pak 16y ago
  How does git not shine on OS X? Installed via Fink or DarwinPorts, I can't find any area in which it doesn't perform equivalently to the linux builds. There is also the lovely GitX on OS X for visualizing repos and staging commits.
  - bsergean 16y ago
    Yep, and compiling git is a piece of cake (on machines with a decent gcc).
    - pgbovine 16y ago
      agreed, i totally hate going thru dependency hell, but on any OS X, if you install the developer tools from the installation DVD, that will give you gcc and the basic libs you need to compile git with no problems. ./configure; sudo make install
ableal 16y ago
I'd say that mercurial ( http://tortoisehg.bitbucket.org/ http://tortoisehg.bitbucket.org/ ) or bazaar ( http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html http://doc.bazaar.canonical.com/migration/en/why-switch-to-b... ) might be good for you. Or even plain old tortoise-svn. There's a certain peace of mind to be had knowing you can roll back to what was working yesterday at 17h30. (P.S. it's easier than the tarball snapshot - right click on folder, commit, type a note. Been down that path ;-)
wvenable 16y ago
Rather than being a competition -- each version control system has it's own advantages and disadvantages. Now on the scale of version control, you're at a zero. Almost anything is better than what you're doing now. Even a solo developer should be using version control. For you, I would highly recommend moving to Subversion. It's relatively simple and has great (and free) integration with Windows Explorer and Visual Studio. And if you want to move up to Git in the future, it's not a terribly difficult transition.
- nearestneighbor 16y ago
  > 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?
RyanMcGreal 16y ago
>Git just isn't well-supported on Windows Msysgit is stable and fully functional. You can even install it so that the git commands are available on the 'DOS' command line.
prog 16y ago
Irrespective of what Torvald says, I would probably choose svn over tarballs. But you should look also at bzr and hg. I don't think they integrate with Visual Studio but have good guis.
suraj 16y ago
I have had wrong code delivered on more than one occasion because of workflow of using tarballs and/or backup folders. If you are working on windows, there is no GUI better than TortoiseSVN. Give TortoiseSVN a try, it won't replace the #ifdef's; but it will certainly be better that tarballs for solo development.

solutionyogi 16y ago

I use Git on Windows with Visual Studio and I don't face any issues whatsoever. Yes, Git is not integrated with VS but I have no trouble switching to explorer and commit my changes using TortoiseGit. TortoiseGit scans my working directory and presents list of all the changes made in a session. And yes, to be on safer side, I copy and store my working directory + Git to a different location.

nearestneighbor 16y ago
Check out these replies: http://stackoverflow.com/questions/1500400/is-tortoisegit-ready-for-prime-time-yet http://stackoverflow.com/questions/1500400/is-tortoisegit-re... It's not just the fragility and lack of integration, but also I'm just not seeing much of a benefit to counterbalance the complexity and awkwardness.
- solutionyogi 16y ago
  Well, I have been using it for 'production' work for last 6 months and I have not found any issues. I am not suggesting that everyone will have the same experience but I think you should give it a try before dismissing it outright based on someone else's experience. Also, if you could provide some real details on the 'complexity and awkwardness', I could share my experience which could be helpful.
  - nearestneighbor 16y ago
    > give it a try before dismissing it Giving it a try can only prove the presence of fragility, not its absence :-) Generally, people are very reluctant to criticize "hip" tools like e.g. Clojure, Haskell, Google Go, Git or its accessories. So, when 3 out of 4 people say they had problems with it, to me it weighs very heavily on the negative side.
    - wvenable 16y ago
      For the record, I agree with you on Git (on Windows at least). It's improved at a rapid pace but it's still a bit awkward. However, that's no reason to dismiss all version control.
      - nearestneighbor 16y ago
        I'm glad you agree, because for the rest of the equation (Tarballs > CVS > SVN), Linus agrees with me. So you see, I embody the combined wisdom of both of you, as far as version control goes.
        wvenable 16y ago
        You have his equation wrong. He says in this article that SVN is still better than CVS. And really, I would agree that tarballs are better than CVS. So the equation is more likely SVN > Tarballs > CVS. Don't put words in Linus's mouth. Also Subversion no longer stores it's data in a database so Linus's objection in this article has been resolved. Finally, Linus's needs are pretty unique in the world. Linus isn't satisfied with Subversion for the same reasons it might work perfectly well for you.
        nearestneighbor 16y ago
        > He says in this article that SVN is still better than CVS. He says SVN is better, but is more fragile (which for source control, I interpret as being worse): SVN fixes (supposedly) those "implementation suckiness" issues. ... I think it's also a much more fragile setup and there's apparently been people who lost their entire database to corruption Even if SVN = CVS, clearly Tarballs > SVN, according to him. His actual quote was Tarballs >> CVS. I can dig it up if you can't.

Locke1689 16y ago

Git is not supposed to shine on OS X. Git was written with the Linux kernel and subsystem in mind. OS X is UNIX, but it is not Linux. Try Mercurial. Git's piss-poor cross platform support has all but removed it from my development routine. Well, that and I find Mercurial's interface far more comfortable to work with.

pak 16y ago
How does git not shine on OS X? Installed via Fink or DarwinPorts, I can't find any area in which it doesn't perform equivalently to the linux builds. There is also the lovely GitX on OS X for visualizing repos and staging commits.
- bsergean 16y ago
  Yep, and compiling git is a piece of cake (on machines with a decent gcc).
  - pgbovine 16y ago
    agreed, i totally hate going thru dependency hell, but on any OS X, if you install the developer tools from the installation DVD, that will give you gcc and the basic libs you need to compile git with no problems. ./configure; sudo make install

ableal 16y ago

I'd say that mercurial ( http://tortoisehg.bitbucket.org/ http://tortoisehg.bitbucket.org/ ) or bazaar ( http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html http://doc.bazaar.canonical.com/migration/en/why-switch-to-b... ) might be good for you. Or even plain old tortoise-svn. There's a certain peace of mind to be had knowing you can roll back to what was working yesterday at 17h30. (P.S. it's easier than the tarball snapshot - right click on folder, commit, type a note. Been down that path ;-)

wvenable 16y ago

Rather than being a competition -- each version control system has it's own advantages and disadvantages. Now on the scale of version control, you're at a zero. Almost anything is better than what you're doing now. Even a solo developer should be using version control. For you, I would highly recommend moving to Subversion. It's relatively simple and has great (and free) integration with Windows Explorer and Visual Studio. And if you want to move up to Git in the future, it's not a terribly difficult transition.

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

RyanMcGreal 16y ago

>Git just isn't well-supported on Windows Msysgit is stable and fully functional. You can even install it so that the git commands are available on the 'DOS' command line.

prog 16y ago

Irrespective of what Torvald says, I would probably choose svn over tarballs. But you should look also at bzr and hg. I don't think they integrate with Visual Studio but have good guis.

suraj 16y ago

I have had wrong code delivered on more than one occasion because of workflow of using tarballs and/or backup folders. If you are working on windows, there is no GUI better than TortoiseSVN. Give TortoiseSVN a try, it won't replace the #ifdef's; but it will certainly be better that tarballs for solo development.