"Jay Freeman \(saurik\)" <saurik@saurik.com> writes:
> Additionally, there are sometimes cases where someone checks an
> amazingly large file into the repository for no good reason; such as ncb
> files (the Visual Studio class browser temporary files, which tend to
> get quite large), but this also goes for large graphics files that they
> were using to test). With CVS I can simply delete the file from the
> server end without causing the clients problems (the CVS client
> specifically supports "this file was removed from the repository" and
> deletes the file locally). With Subversion I don't see a good way to do
> this.
$ svn rm http://path/to/big/ugly/file
Poof, it's gone from the repository, and you didn't even need a
working copy. Next time any client updates, it will be removed
from their working copy.
> Also, with CVS you can do archiving. At some point I can take bodies of
> files that are in attics and therefore not in usage anymore; and
> entirely remove them from the repository off to some backup location
> (saving the active server from having the "hard disk requirements
> _never_ get smaller, only bigger) problem. If that file ever _is_
> needed they can request that it get put back on the server. Subversion
> doesn't seem capable of this either.
That's because Subversion is a true time machine. If I say, 'show me
what this project looked like on 9/3/2000', I shouldn't get an error
telling me that some file needs to be restored in the repository. I
guess this is just a 'purist' view of what a repository should be.
> Best case scenario (to me) would be a system integrated as part of the
> version control for entirely removing revisions. So, if revision 5
> added a file, and revision 6 removed it, revision 5 could be entirely
> deleted, linking the information from 4 directly to 6, and if people
> requested version 5 they got back a nice information bubble about how it
> was removed from the repository.
Already planned -- see issue #516, 'svn obliterate'.
> As for archival, I would want to tell Subversion to transfer from one
> database revisions earlier than a certain point maybe to a separate
> database (understanding that Subversion would probably want to avoid its
> own file format).
This seems doable someday, I suppose. If we can someday support
cross-repository links, then a file's history might be able to point
backwards into a different 'backed up' repsository.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:52 2006