Comparison between VSS and SVN

All documents show that SVN can replace CVs, and the problems and disadvantages of SVN are hidden. Unfortunately, we do not think that SVN is a substitute for CVs, although many defects have been modified. What's more, it even brings people back to VSS. Comparison between CVs and SVN is similar to comparison between C ++ and Java. Obviously, both CVs and SVN are far more powerful than sourcesafe, just as C ++ and Java are much more powerful than basic. CVS represents almost Code Control all functions of the system, although sometimes its implementation is not very convenient. SVN corrected and added some features that CVS does not have. For example, when you create a flag and a branch dubious, no one else will notify you when editing the file. SVN is not a substitute for CVs, but a different system, similar to CVS. It has some unique features, which can be used as a reason to adopt it. These functions make him more suitable for the development environment, such as for PowerBuilder. Here you can find the relative advantages and disadvantages of the two.
1 storage type format
CVS is a version control system based on the RCS file. Every CVS file is just a common file, and some additional information is added. These files simply repeat the tree structure of local files. Therefore, you do not have to worry about any data loss. If necessary, you can manually modify the RFM file.
SVN is based on relational databases (berkleydb) or a series of binary files (fs_fs ). On the one hand, this solves many problems (such as parallel read/write shared files) and adds many new features (such as the transaction feature at runtime .). However, data storage becomes opaque.
2 speed
CVS is slow.
Overall, SVN is indeed much faster than CVS due to different architecture implementations. It only transmits a small amount of information on the network and supports more functions in offline mode. But there is a price. The cost of speed is huge storage (full backup of all workersComposition ).
3 flag & Branch
SVN discards three other things by using signs and branches. In fact, this means that they replace the concept with copying files or directories in the archives to save logs. In this way, both sign creation and branch creation are copies of files in the repository. For the branch: Now the branch is just a separate directory in the warehouse, unlike what else happened in the early days. For a flag: You can no longer add a flag to the code. To some extent, the svn full file number complements this defect. The entire repository in SVN has a version number, but not for a single file.
4. Metadata
CVS only allows file storage.
SVN allows a file to have any number of nameable attributes with full functionality.
5. File Type
CVS was initially designed for text file storage. Therefore, there is almost no support for other file types (binary, unified Code). If necessary, there must be other information, and the client server must be adjusted.
SVN cares about all file types and does not require manual operations.
6. rollback
CVS allows any rollback, even though it takes some time (all files must be processed separately) on any submitted version ).
SVN does not allow rollback after submission. We recommend that you add a good version in the version Library to the end to overwrite the damaged version. However, corrupted versions may also exist in the database. (The SVN rollback operation is actually a merge operation)
7. Transactions
The "zero or one" transaction principle in CVS is not implemented at all. If several files are checked (added to the server), it is very likely that some files have been completed, while the others have not. As a potential rule, manually correct the rules and repeat the remaining files (instead of all files. In this way, these files will be checked in two phases. SVN does support the "zero or one" transaction principle, which is a major advantage of SVN.

Comparison between VSS and SVN

1. Supports renaming, which is very important for Java development.
To get better code, refactoring is often required during development. refactoring often involves file refactoring names, which are not supported in VSS renaming.
2. You do not have to lock it during development.
On the one hand, refactoring is not convenient. On the other hand, offline development is not allowed. SVN is different. You can take it home and continue development. After you come back, submit it.
3. multiple platforms.
Supports operations on multiple platforms
4. Better client support.
The VSS plug-in eclipse is not as useful as its SVN plug-in. A svn client tortoisesvn used in Windows is also easier to use than a vss client (VSS only provides a GUI client provided by Microsoft ).
5. Better Integration with peripheral tools.
A variety of peripheral tools (mainly on the server side) to meet a variety of needs. If necessary, you can also write plug-ins or management scripts, open architecture, and allow us to do so.
6. Convenient.
An example: when deploying an application, the previous method was to find a file modified in the project and update it to the server. Now you can run the svn Export command on the server, export the latest version of the code library to complete deployment (or replace it with the old version ).
7. both speed and stability look good.
It is worth learning about its management and how it works. VSS is a software that has been gradually abandoned. If time is not too much to use, you can spend time on the most worthwhile things.