Why isn't obliterate an essential feature of Subversion?
For some years now, I'm waiting for Subversion to feature a "delete permanently" (obliterate) function. I hesitate to make the transition to Subversion (coming from Visual SourceSafe :p), because I think this is an essential feature, as otherwise I'd expect the repository to grow unstopably. However, for one reason or the other, the feature gets postponed over and over again. So I begin wondering if there is some other feature or workaround which makes the obliterate function dispensable.
What do you do when you want to shrink the SVN central repository?
Example 1: I check in a large third party library, and after a few weeks I realize it is not suited for my needs. I don't want that to store and backup that large amount of data forever.
Example 2: I have 10 versions of 10 big third party libraries in the repository, but I only use the latest versions.
Example 3: I accidentally checked in sensitive information (as suggested by John).
Example 4: I accidentally checked in some big files that were never meant to be put in the repository.
There is a fair amount of discussion of svn obliterate on the problem ticket at the Apache Subversion site, most of it ending about 2008. There seems to be general agreement that it's a good capability to have, although its use should be rare.
There are two main reasons to want it.
First, checking in confidential information can be a problem. Leaving it in there, deleted, is not necessarily an option, depending on the level of confidentiality and exposure of the repository.
Second, checking in a large amount of stuff that shouldn't be checked in can drastically increase the size of the repository. Disk space is generally cheap nowadays, but it isn't unlimited, and there are other ways file space can matter. If it's necessary to send a repository over a net connection, that's extra time which may or may not be important. There can be real advantages to being able to burn a CD-ROM or DVD-ROM that contains the whole repository.
Therefore, it's a useful capability which is currently done by dumping, filtering, and reloading the repository. This is error-prone according to reports I've seen, can be slow, and requires shutting down the repository.
Obviously, it's not a high-priority feature for the Subversion team, given that what it's needed for quite a few years is somebody to do the work to come up with a design and implement it. After all, it should be done very rarely, and there is a workaround. However, anybody who wants to do a whole lot of work on Subversion could provide a patch that would (if good enough quality) probably be implemented.
It violates the meaning of source control.
Source control is all about being able to restore a previous state. If you delete a file permanently you won't be able to.
OTOH i do not know VSS so i might have misunderstood "delete permanently"
The obvious reason against it is because the developers think it will on balance make SVN worse - the happiness you feel at being able to prune un-needed stuff will be vastly dwarfed by your anger when you accidentally obliterate something and your /trunk goes missing.
FogBugz has exactly the same behavior, and in their case it's entirely by design I believe, protecting users from themselves.
链接地址: http://www.djcxy.com/p/37528.html上一篇: 使用Subversion错误需要帮助