Ph. Marek wrote:
> On Donnerstag, 8. November 2007, C. Michael Pilato wrote:
>> Ph. Marek wrote:
>>> Not if both are new files:
>>> $ svnadmin create r
>>> $ svn co file:///tmp/test/r wc
>>> Checked out revision 0.
>>> $ cd wc/
>>> $ date > f1
>>> /wc$ svn add f1
>>> A f1
>>> /wc$ svn cp f1 f2
>>> svn: Cannot copy or move 'f1': it's not in the repository yet; try
>>> committing first
>> Seems it'd be pretty trivial to teach the Subversion command-line that 'svn
>> copy schedule-add-file' should just do a literal file copy and schedule the
>> result for addition (without history).
> If I understand you correctly this is *not* the solution.
>
> Imagine f1 being a 100MB copy of /dev/urandom, or a 2GB video (both
> incompressible) - then you know why I'd like to have some kind of link; even
> if it's a copyfrom, which disturbs the history of f2.
>
> If the files are not in some way related, subversion will store both
> independently - and use too much space.
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.
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.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Thu Nov 8 14:48:07 2007