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

Re: Feature request: option to avoid base copy in WC admin area

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2006-07-21 15:03:49 CEST

> Now for the request:
> Would it be difficult to add a mechanism to avoid storing the duplicate base
> copy of every file in the administrative area?

That's issue 525!


Maybe you could donate some design and development resources?

To comment on your ideas:
- Lots of code in libsvn_wc actually presumes these files exist (which
is why I think that in the short term issue 908 is more tractible)
- Mechanisms already exist to retrieve specific files at a given
revision without the need to run a full update (so, technically,
retrieving 1 file should not be a problem)
- Some operations depend on sending deltas, but when a delta is
generated against a zero-length file, this delta does not depend on
the predecessor (since you faked that there was none): this is not the
hard part.
- I'd prefer to work without base files entirely. If someone starts
complaining that *that* doesn't work for him, we can try to figure out
a partial caching implementation. (just IMHO)
- I don't have any ideas on where the setting would be located best
(props or client config). I'd say: at least repository config (which
we don't have) but directory prop would seem fine to me.
- If you can donate anything wrt this issue getting resolved, please
join dev@subversion.tigris.org and start a thread either stating your
plans, or just informing what you can do.

BTW: There could be another concern before moving your binary assets
into subversion: there's no 'svn obliterate' command, so, you can
never remove history from your repository. Especially with art work,
this can make it grow quite a bit.



To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 21 15:05:18 2006

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.