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.
Regards,
Phil
---------------------------------------------------------------------
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