On 23.04.2015 16:59, Julian Foad wrote:
> Marc Strapetz wrote:
>> Using copy with the new metadataOnly option (through the API) only allows to
>> "move" or "copy" a missing file onto an unversioned file. It could also be
>> helpful to copy/move metadata from a removed (or replaced) source to an
>> already added (or replaced) target.
>>
>>
>> Use case 1: the user has removed file "a" and moved file "b" to file "a"
>> without using SVN:
>>
>> $ svn status
>> M a
>> ! b
>>
>> Goal is to preserve "b"'s history for the new "a" and have the history of
>> the old "a" being ended.
>
> Marc,
>
> If I understand correctly, the goal of this example is to make the
> version control operations reflect the filesystem operations, so that
> we end up with:
>
> path 'a': replaced with a copy from 'b'
> path 'b': deleted (or rather the object that was here has been moved
> to path 'a')
That's correct.
>> With metadataOnly being more tolerant, this could
>> then be done by:
>>
>> $ svn rm --keep-local a
>> $ svn add a
>> $ svn cp --metadata-only b a
>
> I don't understand why you suggest that sequence of commands. I don't
> expect 'svn cp' should allow copying to a destination that's already
> under version control (that is, 'a' after 'svn add a'), metadata-only
> or not. I would expect 'svn cp --metadata-only' to do everything just
> the same as plain 'svn cp' except not touch or look at what's on disk:
> so not try to copy the disk file and not care about whether the file
> is present on disk at either the source or target location.
>
> Therefore I think the appropriate sequence for your example would be:
>
> $ svn rm --keep-local a
> $ svn mv --metadata-only b a
I agree that this would result in the same state (though currently
doesn't work, too).
The reason why I was using the additional "svn add" is that SmartSVN
provides two GUI commands for this procedure:
- "mark as replaced" which is applicable on a modified file and turns
this one into a replaced file by invoking:
$ svn rm --keep-local a
$ svn add a
- "move" which is applicable on a single, versioned file and on two
files for which one must be missing and the other one unversioned. The
latter two-files-version invokes:
$ svn mv --metadata-only b a
With a hack, the two-files-version is (resp. was) also applicable on
combinations like (missing, added), (missing, replaced), (removed,
added), (removed, replaced) ...
With "mark as replaced" and "move" both uses cases could be satisfied
and it is still close to the user's thinking: a has been replaced, hence
split the history of a, a is actually b, hence link b's history with a.
For:
$ svn rm --keep-local a
$ svn mv --metadata-only b a
This can also be done with two GUI commands: "remove" and "move",
however the procedure isn't that close to the user's thinking: it
requires him to remove a file to make place for a "virtual" move
operation which would otherwise fail. This is harder to comprehend, at
least IMO.
For command line usage, I would agree that --metadata-only should
probably be limited to (missing, unversioned) to avoid possible misusage
directly by the user. The API could be more flexible, assuming clients
using the API will pass this flexibility only in a controlled and
careful way to the user :)
-Marc
Received on 2015-04-23 17:46:03 CEST