Comment Re:Reasons _NOT_ to use subversion: (Score 1) 326
Revisited
branching is woefully inefficient on the storage side:
Incorrect as far as "storage" is concerned. branching is virtual, but.... a branch or a tag is the same thing in SVN. The result is a duplication of the directory and file nodes without the base content. Only the deltas are stored. This method is lean on space usage but consumes filesystem directory entries at an alarming rate for systems with a lot of tags or branches. This may be acceptable for single-project-per-repository, but is unlikely to scale well for large numbers of projects with many tags and branches.
merging is (practically) unsupported:
Merging is only supported using the actual version numbers, not tags. Specifically, the merge command syntax requires the user to determine what version numbers are associated with what tags so as to perform the merge using the version numbers.
there is no rollback from a commit, because....:
Design decision.
it uses BerkeleyDB as the management system.. and that is bad because...:
An alternative to BDB has been released in 2004. The FSFS solution for SVN is more like the CVS solution being based on special files. The solution is not without its own problems (see the link: )
Oracle now own Sleepycat software (the makers of BDB):
Claimed as "irrelevant" by SVN supporters, but the question begs as to how long a major corporation is willing to support free (as in beer) software for non-core business still is unresolved.
A detailed explanation of how tagging/branching operates in SVN is definitely required in order to clearly understand why it can be a problem for repositories that contain multiple projects with many tags and branches. In short, the SVN manual says that the operation of tagging or branching is treated the same. A "svn copy" command is issued. This is the root of why so many people (including me until recently) believed that the back-end storage would be very inefficient. The "copy" is referred to by SVN zealots as a "cheap copy" because it is an almost constant time operation. What the documentation says occurs is that links are made to the original repository area and the file deltas are recorded in the new tree. Conceptually this means that space consumption is very small being only a small growth in the size of some control files and creation of some directories. Realistically, there is a practical limit on the number of directory entries that can be made in a system. So for a very large repository containing many modules, tags and branches, then the growth rate in directory entry usage would be significant if not unsustainable. Partitioning the repository into multiples spanning several servers may be the only way to scale that adequately. CVS suffers from a similar problem, but not to quite the same extent as multiple tags on the same file version would not cause duplications. The SVN solution of forcing a version to represent all the files in a project (compared to CVS where each file has separate version numbers) leads to some simplifications and some complications.
One of the various explanations of how it works :
The structure of SVN is interesting and in some cases disturbing.
http://subversion.tigris.org/design.html#server.fs .struct.bubble-up
a summary...
The reasons to move to SVN are based primarily on the claims that CVS is not an active open source project any more and that it is losing support. Those claims are misleading. CVS has moved from being a "constantly updated to fix and enhance" open source project to being a stable product now under the GNU banner.
The reasons to stay with CVS would be largely dictated by practical issues.
The migration of a multiple-project CVS repository to SVN appears on the surface to be an unsustainable move. Ideally, the projects would be split into separate repositories if such a migration was to be performed.
The clients deployed to users would all have to be changed and a significant amount of user training would be required.
A number of automated and semi-automated systems would have to be reworked significantly in order to migrate to SVN as they have embedded CVS-based tasks
I don't know if the pain of migration would be worth the somewhat questionable benefits (IMHO) of transitioning to SVN.
branching is woefully inefficient on the storage side:
Incorrect as far as "storage" is concerned. branching is virtual, but.... a branch or a tag is the same thing in SVN. The result is a duplication of the directory and file nodes without the base content. Only the deltas are stored. This method is lean on space usage but consumes filesystem directory entries at an alarming rate for systems with a lot of tags or branches. This may be acceptable for single-project-per-repository, but is unlikely to scale well for large numbers of projects with many tags and branches.
merging is (practically) unsupported:
Merging is only supported using the actual version numbers, not tags. Specifically, the merge command syntax requires the user to determine what version numbers are associated with what tags so as to perform the merge using the version numbers.
there is no rollback from a commit, because....:
Design decision.
it uses BerkeleyDB as the management system.. and that is bad because...:
An alternative to BDB has been released in 2004. The FSFS solution for SVN is more like the CVS solution being based on special files. The solution is not without its own problems (see the link: )
Oracle now own Sleepycat software (the makers of BDB):
Claimed as "irrelevant" by SVN supporters, but the question begs as to how long a major corporation is willing to support free (as in beer) software for non-core business still is unresolved.
A detailed explanation of how tagging/branching operates in SVN is definitely required in order to clearly understand why it can be a problem for repositories that contain multiple projects with many tags and branches. In short, the SVN manual says that the operation of tagging or branching is treated the same. A "svn copy" command is issued. This is the root of why so many people (including me until recently) believed that the back-end storage would be very inefficient. The "copy" is referred to by SVN zealots as a "cheap copy" because it is an almost constant time operation. What the documentation says occurs is that links are made to the original repository area and the file deltas are recorded in the new tree. Conceptually this means that space consumption is very small being only a small growth in the size of some control files and creation of some directories. Realistically, there is a practical limit on the number of directory entries that can be made in a system. So for a very large repository containing many modules, tags and branches, then the growth rate in directory entry usage would be significant if not unsustainable. Partitioning the repository into multiples spanning several servers may be the only way to scale that adequately. CVS suffers from a similar problem, but not to quite the same extent as multiple tags on the same file version would not cause duplications. The SVN solution of forcing a version to represent all the files in a project (compared to CVS where each file has separate version numbers) leads to some simplifications and some complications.
One of the various explanations of how it works :
The structure of SVN is interesting and in some cases disturbing.
http://subversion.tigris.org/design.html#server.f
a summary...
The reasons to move to SVN are based primarily on the claims that CVS is not an active open source project any more and that it is losing support. Those claims are misleading. CVS has moved from being a "constantly updated to fix and enhance" open source project to being a stable product now under the GNU banner.
The reasons to stay with CVS would be largely dictated by practical issues.
The migration of a multiple-project CVS repository to SVN appears on the surface to be an unsustainable move. Ideally, the projects would be split into separate repositories if such a migration was to be performed.
The clients deployed to users would all have to be changed and a significant amount of user training would be required.
A number of automated and semi-automated systems would have to be reworked significantly in order to migrate to SVN as they have embedded CVS-based tasks
I don't know if the pain of migration would be worth the somewhat questionable benefits (IMHO) of transitioning to SVN.
