On Thu, May 13, 2004 at 10:26:47PM -0700, Pete Gonzalez wrote:
> Does Subversion have something like this? If not, it seems like
> it would be pretty trivial to implement, since it basically
> involves subtracting existing functionality rather than implementing
> something new. :-)
Nope. I need the same thing, and the only solution I've found is to use
CVS for the data tree and SVN for the source tree, which is a pain (but
better than using CVS for everything).
The general response to this seems to be "why are you putting data in
version control if you don't want it versioned"; the answer is that svn
isn't just version control--it's a respository.
There also seems to be a strong (and valid) design concept of "never lose
data", but removing data is not losing data. My filesystem doesn't lose
data, but that doesn't mean it doesn't support unlink().
I don't think it would be trivial, though--nothing useful is ever trivial.
For example, the protocol is based on sending diffs--if old revisions
aren't kept, the server can't produce diffs, since it doesn't have the
client's old revision.
> A related feature would be the ability to delete old revisions.
> For example, we have some relatively ancient revision histories
> in our repository, and it would be nice to issue a command such
> as "Collapse all changes between Jun 1, 2003 and Jan 1, 2004
> into a single revision." This would not only reduce the database
This was my original question; I think being able to say "keep only the
latest copy, don't version" is more useful and require less babysitting,
though.
> footprint, it could also dramatically reduce the amount of time
> you have to wait for operations such as the revision history
> window in TortoiseSVN. (I realize that it might be possible to
> accomplish this with a 200-step manual procedure involving
> "svnadmin dump," but maybe it could be automated?)
The "dump" procedure has problems: it requires taking the repository
down, takes a long time, and requires that you have enough space to
store at least one extra copy of the repository (and if you're doing
this to free up space, you probably don't). I think you can only delete
entire ranges of revisions this way, too, not revisions for specific
files, at least without doing special dump filtering. Also, it has the
update problem: clients that have revisions that you deleted won't
be able to update cleanly.
I think there's an issue open for implementing a simpler way to wipe out
revisions, but if I remember correctly, it's expected to still have most
of the above problems.
> Is anyone else working on large projects? A lot of the postings
> on this list seem to be from people who are just setting up
> Subversion or who have relatively small projects.
We deal with about a gig of data right now, and we only have a few gigs
on our server (server space is expensive).
--
Glenn Maynard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 14 08:57:44 2004