Hyrum K. Wright wrote:
> Julian Foad wrote:
>>Hyrum K. Wright wrote:
>>>This patch modifies the move subcommand to accept more than two
>>>arguments, similar to the unix mv command. If there are only two
>>>arguments, the command continues the current behavior. If there are
>>>more than two, it checks to see if the last one is a directory, and if
>>>it is, moves the preceding targets into it.
>>Thanks for the patch. I would like this enhancement. I have some
>>(1) "copy" is very similar to "move", and should be modified in this way
>>at the same time.
>>(2) The current behaviour of "svn move" (with respect to how the
>>destination is interpreted) is not documented in its help text. We need
>>to decide whether we are happy with it, and document it, first, so that
>>we can make sure the multiple-source behaviour is consistent with the
>>In the existing two-argument "svn move", I believe that if the target
>>already exists and is a directory, the source is copied INTO the
>>destination dir, otherwise the source is copied TO the destination.
>>This is under discussion at the API level in the thread "API proposal -
>>issue 2188 - svn_client_copy/move". Similar arguments apply to the
>>command-line interface, but the desired interface may well differ (and,
>>in particular, needs to be backward-compatible).
>>>Right now, this change lives in the client, but would it be better to
>>>have the multiple move logic live somewhere lower down the stack, such
>>>as the wc layer?
>>Yes. At least for the case of a move performed directly on a
>>repository, it needs to be done at a lower layer so that the move is
>>done in one commit and not N commits.
> Thanks for the comments and review. Upon further thought, here's a
> proposed plan of attack for implementing this feature for both the copy
> and move commands. If there are any fatal flaws in my reasoning, please
> point them out.
A note about terminology. "Target" is ambiguous: when talking about Subversion
commands like "commit", "target" means a file or directory on which the command
operates. When talking about a move or a copy, "target" often means the
destination as opposed to the source. So it would be clearer to use only the
terms "argument", "source" and "destination". However, when you talk about
more than one target it is clear that you mean the arguments. Unfortunately
the term "client layer" is also ambiguous. In Subversion there are two client
layers: the client library (libsvn_client) and the client application (svn). I
see from your point (2) below that you mean the library, libsvn_client.
> 1) In the command line client, let anything with more than 2 targets get
> through to the client layer.
Yes: all copy and move operations should get through to libsvn_client,
including those with more than two arguments. They may well have to get
through to a lower layer than that.
> 2) In the client layer, rev svn_client_move so that it takes multiple
> targets, not just a src_path and dst_path.
Right. To be more precise, it will take multiple source arguments and a single
> 3) Actually do determination of multiple moves or copies in the client
> layer, making multiple calls to the correct copy handler.
Well, again, it needs to implement the repository version of the operation as a
single commit, so I don't think it can make multiple calls to the lower layer,
but that depends on the lower layer's API and I haven't looked at it.
> A few questions this brings up are:
> Should we allow a heterogeneous list of targets to move, such as:
> svn mv alpha file:///path/to/repo/beta gamma dir1
> or do all of the targets to move need to be either wc paths or URLs, but
> not both?
Currently "move" requires the source and the destination to be both in the WC
or both in the repository, and I don't think we should change that requirement.
However, "copy" does not have that restriction on its source and destination.
Nevertheless I don't think we need to allow mixed sources in a copy; all
sources should be in the WC or all in the repository.
> Relatedly, the current command line documentation seems to imply that
> both the SRC and the DST have to be working copy paths or URLs, but the
For "move", yes. For "copy", no, they don't have to be the same type.
> client layer has functions for copying from the WC to a URL and vice
For "copy", yes; but not for "move".
> versa. Should that documentation be updated?
No, it's correct. The restriction on "move" makes sense because both the
source and destination of a move have to be written to in the same operation.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Nov 8 17:53:17 2005