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.
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.
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.
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).
Sincerely,
Jay Freeman (saurik)
saurik@saurik.com
-----Original Message-----
From: sussman@collab.net [mailto:sussman@collab.net]
Sent: Tuesday, December 11, 2001 3:55 PM
To: Dan Berger
Cc: kfogel@collab.net; dev@subversion.tigris.org;
users@subversion.tigris.org
Subject: Re: question: repository backups?
Dan Berger <dberger@ix.netcom.com> writes:
> > > 1. Operational Concerns: One of the nice things about CVS is that
the
> > > repository is transparent - you can tar it up, move it around,
dump it
> > > to tape like any other file system - do incremental backups, etc.
Can
> > > someone on this list discuss how subversion intends to address
> > > day-to-day repository maintenance?
The svn repository is a directory full of Berkeley .db files and
scripts. You can tar it up, move it around, dump it to tape. You can
do 'hot backups' -- we have a script that does that already (in our
source tree.)
Read about Berkeley DB at www.sleepycat.com. The repository is really
just a berkeley 'environment'.
...
---------------------------------------------------------------------
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