Hacker News Reader

Comment by sk5t | Hacker News Reader

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.

View on HN

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.

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.

Non centralized is probably the best one. But agree it's harder from there.

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.

I'm effectively using SVN as a CMS in this case - its just an easy way to sync files between workstations.

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.

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).

other than a very, very robust aversion to learning anything new.

I may have to borrow that line at my day job sometimes.

Reply on news.ycombinator.com