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

Re: Can svn_fs_copy() copy from txn nodes in the same txn?

From: Ph. Marek <philipp.marek_at_bmlv.gv.at>
Date: 2007-11-08 14:55:08 CET

On Donnerstag, 8. November 2007, C. Michael Pilato wrote:
> Subversion doesn't strictly care about saving you space. It's a version
> control system, not a data compression system. It's job is to track
> versions of files while preserving the historical relationships between
> those versions, period.
Exactly - I'm with you here.

> Arguably, 'svn copy' can be defined as "Fork the version history of some
> file to a second location." If you run 'svn copy' on an unversioned file
> (which, of course, is exactly what a schedule-add file is), then there's no
> version history to fork, which is why 'svn copy' fails with an error today.
> As a nicety to users who object to the failure, I think it'd be perfectly
> fair for 'svn copy' to just do the naive copy and add-without-history. But
> perhaps its best to maintain the failure and let folks do the right thing
> -- put their file under version control, and *then* fork its version
> history.
Ok - then you'll need two commits.

But what issue 2286 is about, is to store identical files only once in the
repository. Whether the repository layer itself find the identity-ness (eg.
by MD5 lookup), or whether the client send some kind of "svn:link"="rev:file"
on commit, to achieve data linking (and space savings), is to be discussed.

Sure, that's not strictly necessary for a versioning system - but it might
save an appreciable amount of space, even for sourcecode-only repositories.

And it gets more important if you keep 2GB videos instead of 20kB textfiles.



To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 8 14:55:46 2007

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

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