[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Disk space recovery

From: Glenn Maynard <g_sub_at_zewt.org>
Date: 2004-03-23 23:15:41 CET

On Tue, Mar 23, 2004 at 03:56:33PM +0200, Nuutti Kotivuori wrote:
> Remember that Subversion works based on diffs sent over the
> network. So if some of your users have an older working copy and wish
> to get up to date, the repository must have the older version to
> compare against it. Changing the system to send full-texts in these
> cases wouldn't be a minor change.

Especially if the "don't version" is, itself, a versioned property.

"svn obliterate" would have to deal with this, too: if a WC has revision
1, and we delete that revision, "svn update" on that copy would have to
receive a full copy.

> Some day "svn obliterate" will come in to existence, and hopefully it
> will support removing only a subset of versions on a file.

Well, not just removing: replacing with the current (or the next). For
example, if a file has two revisions, 1 and 2, and we remove 1, it should
actually replace 1 with 2. That way, if we look at revision 1 of the
repository, the file isn't missing; we simply see the latest revision,
instead of what was really there at the time. (The issue of branches
needing to be rewritten wouldn't affect me, at least; we won't be branching
this data.)

Also, I hope "svn obliterate" won't need to write out a second copy of
the entire db; that'd have the same problem as svnadmin dump/filter/load:
requiring a lot of free disk space, making it useless for disk space

Glenn Maynard
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 23 23:16:08 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.