4 ms·

> I still use Visual Source Safe for my personal projects. It's never failed me in 20 years. Right click, check out, right click checkin. Perfect every time. 1

by robzyb 11y ago

> I still use Visual Source Safe for my personal projects. It's never failed me in 20 years. Right click, check out, right click checkin. Perfect every time. 1st reaction: Horrified that you are still using VSS. 2nd reaction: Was that if it does what you need it to, well, then, who am I to judge? It doesn't matter whether the tool was created yesterday or 20 years ago. 3rd reaction: Does it really do what you need it to do? I would guess that maybe svn/git has some simple featured that would significantly improve your life. 4th reaction: Wasn't VSS known as being super buggy? Is it just luck that you've escaped failure in 20 years?

sk5t 11y ago
This is horrifying indeed. I cannot imagine any reason to go on using VSS other than a very, very robust aversion to learning anything new. And yes, VSS is very buggy, although the bugs might not show up for a single-user environment always following the happy path.
- my5thaccount 11y ago
  I've used git on several hosts and subversion back in the day. I have no problem learning new things. Tortoise, bitbucket, github, beanstalk to name a few. I think your reaction is more horrifying than me not having a compelling reason to change the way I've been doing things without flaw for decades.
  - Aloha 11y ago
    So long as it works for you, thats great - I just hope you have a migration path if/when it stops working. I do however get the objection to newer is better, I keep getting besieged to move my projects from svn to git - to which I usually respond "Why, tell me what feature we need in git, that svn doesn't do?" I've yet to get an answer.
    - supercoder 11y ago
      Non centralized is probably the best one. But agree it's harder from there.
    - cesarb 11y ago
      If you "keep getting besieged to move [your] projects from svn to git", I can guess that who is asking is probably downstream consumers of your projects. What they might actually be wanting: - Familiarity. Everyone uses git nowadays; like it or not, svn projects are the odd ones out. - Fast, offline querying of the project's history. With git, they have a full copy of the project's history in their local computer, while with svn, any query has to go to the server. This helps a lot when chasing regressions, or just when browsing the changes between one release and the other. - Easy branching. Branches in git are more lightweight than branches in svn, and git's merge functionality is quite good. When they want to propose some change to your code, they can just create a branch in their local copy, make the changes they want, publish the branch somewhere, and ask you to merge it; this is made even easier by sites like github. With svn, unless they have an account in your svn server, they have to do it the old-fashioned way.
      - Aloha 11y ago
        I'm effectively using SVN as a CMS in this case - its just an easy way to sync files between workstations.
  - sk5t 11y ago
    I'm not trying to be mean. If one is going to stick with an obsolete source control system--as an important part of one's work process--there should be a good reason for doing so; however, one cannot make such a justification based on ignorance of the alternatives unless the two hours to learn, e.g., git, cannot be spared and would not be recouped in future productivity.
- dec0dedab0de 11y ago
  other than a very, very robust aversion to learning anything new. I may have to borrow that line at my day job sometimes.
- to3m 11y ago
  I don't know if they fixed VSS in later versions, but I used it in a team environment from 2000-2002, and heard of other people using it similarly even later than that (including for art assets as well as code...), seemingly without any problems. As well as the oft-unjustly-maligned check in/check out model, two other things it has going for it are that administration is pretty easy and it has both a command line client and a GUI client. (Which might sound like a ridiculous thing to say, but I have used some systems that have one but not the other - hopefully very rare these days though.) This isn't really a recommendation for it, though, unless they've put a huge amount of work into it over the past fifteen-odd years (which somehow I doubt). To get the same check in/check out workflow, you could try Perforce (though I heard from somebody that did it on AWS that the initial setup can be a bit fiddly) or SVN (though check in/check out evidently isn't quite how it's designed to be used, because (a) this is not the default, and (b) the performance can be pretty crappy).

by robzyb 11y ago

sk5t 11y ago

This is horrifying indeed. I cannot imagine any reason to go on using VSS other than a very, very robust aversion to learning anything new. And yes, VSS is very buggy, although the bugs might not show up for a single-user environment always following the happy path.

my5thaccount 11y ago
I've used git on several hosts and subversion back in the day. I have no problem learning new things. Tortoise, bitbucket, github, beanstalk to name a few. I think your reaction is more horrifying than me not having a compelling reason to change the way I've been doing things without flaw for decades.
- Aloha 11y ago
  So long as it works for you, thats great - I just hope you have a migration path if/when it stops working. I do however get the objection to newer is better, I keep getting besieged to move my projects from svn to git - to which I usually respond "Why, tell me what feature we need in git, that svn doesn't do?" I've yet to get an answer.
  - supercoder 11y ago
    Non centralized is probably the best one. But agree it's harder from there.
  - cesarb 11y ago
    If you "keep getting besieged to move [your] projects from svn to git", I can guess that who is asking is probably downstream consumers of your projects. What they might actually be wanting: - Familiarity. Everyone uses git nowadays; like it or not, svn projects are the odd ones out. - Fast, offline querying of the project's history. With git, they have a full copy of the project's history in their local computer, while with svn, any query has to go to the server. This helps a lot when chasing regressions, or just when browsing the changes between one release and the other. - Easy branching. Branches in git are more lightweight than branches in svn, and git's merge functionality is quite good. When they want to propose some change to your code, they can just create a branch in their local copy, make the changes they want, publish the branch somewhere, and ask you to merge it; this is made even easier by sites like github. With svn, unless they have an account in your svn server, they have to do it the old-fashioned way.
    - Aloha 11y ago
      I'm effectively using SVN as a CMS in this case - its just an easy way to sync files between workstations.
- sk5t 11y ago
  I'm not trying to be mean. If one is going to stick with an obsolete source control system--as an important part of one's work process--there should be a good reason for doing so; however, one cannot make such a justification based on ignorance of the alternatives unless the two hours to learn, e.g., git, cannot be spared and would not be recouped in future productivity.
dec0dedab0de 11y ago
other than a very, very robust aversion to learning anything new. I may have to borrow that line at my day job sometimes.
to3m 11y ago
I don't know if they fixed VSS in later versions, but I used it in a team environment from 2000-2002, and heard of other people using it similarly even later than that (including for art assets as well as code...), seemingly without any problems. As well as the oft-unjustly-maligned check in/check out model, two other things it has going for it are that administration is pretty easy and it has both a command line client and a GUI client. (Which might sound like a ridiculous thing to say, but I have used some systems that have one but not the other - hopefully very rare these days though.) This isn't really a recommendation for it, though, unless they've put a huge amount of work into it over the past fifteen-odd years (which somehow I doubt). To get the same check in/check out workflow, you could try Perforce (though I heard from somebody that did it on AWS that the initial setup can be a bit fiddly) or SVN (though check in/check out evidently isn't quite how it's designed to be used, because (a) this is not the default, and (b) the performance can be pretty crappy).