What is the difference between svn and vss

Net projects for about 6 months. If the project was in VSS before, there's some problems with bindings. There is a tool called "Source Safe Binding Remover" for helping remove these bindings.

It deletes every. NET projects as well as with my old FoxPro projects-the process is no different, which is great for consistency and allows storage of all sorts of files from. VSS's lock-modify-unlock model makes collaboration on rapidly-changing files a major headache. Plus the overhead of needing an admin to unlock files that someone has checked out while they're on vacation.

Your source repository is supposed to be a rock - if a developer's workstation crashes, you should only have lost HIS changes.

You shouldn't lose random files and data from the repository VSS hasn't been maintained by MS in over 6 years. Can you even get support for it anymore? Depending on your backup tools, you may not be able to get a complete backup of your VSS repository if you have just one person left logged into the server meaning they left their dev tools open, or left the VSS client running. VSS requires that all users have nearly full control, at the filesystem level NTFS permissions , of the files that make up the repository.

Merging sucks in VSS. VSS: If you have developers spread across multiple timezones, the very act of both of them checking in can corrupt the database if they check in too close together, in the wrong order.

If you will choose SVN. I always understood that Microsoft never used Visual SourceSafe for anything. At all.

The number of programmers doubled and we didn't want to fork out for the extra VSS licenses Bugs. VSS is good at maintaining the latest version of a file, but histories often got corrupted. More bugs. VSS has no cost, requires no server other than a file share. Lowest common demoninator. It generally does work, and a number of shops use it. I would rather have VSS as an option than for it to not exist. The fact that it relies on a file share rather than a server is the root of most of its deficiencies.

VSS, while admittedly better than nothing, is epidemic. It's surprising how many shops don't know there are better, free alternatives out there. Martin C. You mean 6. Which was last released in with the. NET 1. Metric Crap Ton? I lolled at that!

You are right. I should have been more specific. I am currently using the version 8. Bert Huijben Bert Huijben Tim Cooper k 36 36 gold badges silver badges bronze badges. Brian Behm Brian Behm 5, 1 1 gold badge 22 22 silver badges 29 29 bronze badges. Nick Berardi Nick Berardi Atomic Commits. Git: Yes. Commits are atomic. Mercurial: Yes. Subversion: Commits are atomic. Visual SourceSafe: No.

VSS commits are not atomic. Files and Directories Moves or Renames. Git: Renames are supported for most practical purposes. Git even detects renames when a file has been changed afterward the rename.

However, due to a peculiar repository structure, renames are not recorded explicitly, and Git has to deduce them which works well in practice. Renames are supported. Subversion: Yes. There is a kludgy workaround using "share-rename,move,delete" that gets what you want. Intelligent Merging after Moves or Renames. Git: No. The effect is indistinguishable from removing the file and adding another with different name and the same content.

Mercurial: Yes, intelligent merging after renames is supported. This is something you might expect to 'simply work,' but not all revision control systems actually do this. Subversion: No. Visual SourceSafe: No, renames are not intelligent. File and Directory Copies. Copies are not supported. Copies are supported. And it's a very cheap operation O 1 that is also utilized for branching. Visual SourceSafe: Yes. Copies are supported up to a point.

Remote Repository Replication. This is very intrinsic feature of Git. Visual SourceSafe: Not directly possible with the included GUI or command line tools; ssarc and ssrestor might be useable. Propagating Changes to Parent Repositories. And there is probably a reason they don't use it.

They use something close to CVS a command line tool. I'm relatively new to using subversion for a small startup of mine but I have and continue to use VSS in my day job.

Hence my choice of subversion for my own use. The best thing about SourceSafe is the price. Everything is else terrible. I've had to extract and rebuild the whole repository three times in 2 years. The corruption is terrible. We've gone through periods where we'd lose several files each day. Marc Leith marc mleith.

Heh Well, since this is the Subversion users list: The only way SourceSafe could beat us on price is if Microsoft pays you to run it. Here's my list of "why I hate SourceSafe". With the noted exceptions, Subversion gets all these things right. If you edit one, and don't realize that it's shared i.

To be fair, though, Subversion supports neither "hard" nor symbolic links; they merely mumble that they plan such support after the 1. You can see how your working copy differs from the current version of the repository, but if someone has checked in changes since you did "get latest", you'll see diffs between your stuff and that, not just the changes you made.

And comparing your working directory with the repository as above is even more agonizingly slow than generating a history list You cannot add a label to a point in the past; you can only label the repository "right now". And who knows what might change while the label is being applied; there's no guarantee of atomicity.

You cannot delete a label; you can only change its text.