You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Max Bowsher <ma...@ukf.net> on 2005/04/01 16:46:58 UTC
API proposal - issue 2188 - svn_client_copy/move
svn_client_move has been revved to svn_client_move2 in 1.2, which makes it
an attractive idea to get some further planned changes to this API out of
the way now too.
See issue 2188 for details, but the short version is:
Clients of our API want to be able to disable the implicit behaviour of "if
copy destination exists and is a directory, append basename of the source to
the destination" that we have now. This behaviour makes sense in some
circumstances, but can prove a great annoyance in others.
So, the initial obvious solution is trivial - a new boolean parameter.
HOWEVER, I think there is a better API change:
Add a new tri-state enum parameter:
enum {
svn_copymove_collision_error,
svn_copymove_collision_make_child,
svn_copymove_collision_replace
};
To illustrate, file:///repos/A and file:///repos/B are two directories that
exist:
svn_copymove_collision_error:
svn cp file:///repos/A file:///repos/B
- causes error.
svn_copymove_collision_make_child:
svn cp file:///repos/A file:///repos/B
- copies A to file:///repos/B/A
svn_copymove_collision_replace:
svn cp file:///repos/A file:///repos/B
- is equivalent to:
svn rm file:///repos/B
svn cp file:///repos/A file:///repos/B
except that it uses only 1 revision number.
I am particularly interested in this, because I have seen emails from quite
a few disappointed users wanting to "move a tag" in just 1 revision, instead
of the 2-stage process which is the only workaround now (rm, cp).
Note that I haven't specified a UI.
In view of the impending 1.2 branch, I just want to get an acceptable API
in, in time to avoid requiring yet another round of deprecation.
The UI design can be hammered out under less rushed conditions.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: API proposal - issue 2188 - svn_client_copy/move
Posted by Philip Martin <ph...@codematters.co.uk>.
"Max Bowsher" <ma...@ukf.net> writes:
> svn_copymove_collision_error:
> svn cp file:///repos/A file:///repos/B
> - causes error.
>
> svn_copymove_collision_make_child:
> svn cp file:///repos/A file:///repos/B
> - copies A to file:///repos/B/A
Suppose file:///repos/B/A exists, does it then do collision_error or
collision_replace?
> svn_copymove_collision_replace:
> svn cp file:///repos/A file:///repos/B
> - is equivalent to:
> svn rm file:///repos/B
> svn cp file:///repos/A file:///repos/B
> except that it uses only 1 revision number.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: API proposal - issue 2188 - svn_client_copy/move
Posted by Martin Hauner <ma...@gmx.net>.
Philip Martin wrote:
> "Max Bowsher" <ma...@ukf.net> writes:
>
>
>>Philip Martin wrote:
>>
>>>"Max Bowsher" <ma...@ukf.net> writes:
>>>
>>>
>>>>svn_client_move has been revved to svn_client_move2 in 1.2, which
>>>>makes it an attractive idea to get some further planned changes to
>>>>this API out of the way now too.
>>>
>>>There is another enhancement that has been requested: allow multiple
>>>source URLs to be moved or copied into a single destination URL,
>>>i.e. make the source argument into an APR array.
>>
>>Does it have an issue?
>
>
> I don't think so.
>
>
>>What are the intended semantics for existant/non-existant
>>destinations?
>
>
> I asked that question at the time. I think the only sensible thing is
> to require that the destination must be a directory and must exist,
> then it works like your make_child.
Yes, that's exactly what i would like to have.
In the gui select multiple files from a files list and than drag & drop
them to another existing directory.
I can work around this for a working copy by calling move mutiple
times by myself but this will not work for repository moves as it would
bring up the commit dialog for each single file.
--
Martin
Subcommander, http://subcommander.tigris.org
a x-platform Win32/Unix svn gui (qt) client & a text diff/merge tool.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: API proposal - issue 2188 - svn_client_copy/move
Posted by Philip Martin <ph...@codematters.co.uk>.
"Max Bowsher" <ma...@ukf.net> writes:
> Philip Martin wrote:
>> "Max Bowsher" <ma...@ukf.net> writes:
>>
>>> svn_client_move has been revved to svn_client_move2 in 1.2, which
>>> makes it an attractive idea to get some further planned changes to
>>> this API out of the way now too.
>>
>> There is another enhancement that has been requested: allow multiple
>> source URLs to be moved or copied into a single destination URL,
>> i.e. make the source argument into an APR array.
>
> Does it have an issue?
I don't think so.
> What are the intended semantics for existant/non-existant
> destinations?
I asked that question at the time. I think the only sensible thing is
to require that the destination must be a directory and must exist,
then it works like your make_child.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: API proposal - issue 2188 - svn_client_copy/move
Posted by Julian Foad <ju...@btopenworld.com>.
Max Bowsher wrote:
> Philip Martin wrote:
>> "Max Bowsher" <ma...@ukf.net> writes:
>>> svn_client_move has been revved to svn_client_move2 in 1.2, which
>>> makes it an attractive idea to get some further planned changes to
>>> this API out of the way now too.
Yes: in particular, the removal of uncertainty (issue #2188).
This applies to "copy" as well as "move", and we should have no qualms about
"revving" the svn_client_copy API as well.
First observation: Good Grief! The API documentation doesn't mention any
possibility of the destination path being interpreted differently depending on
whether it already exists and whether it is a file or directory.
>> There is another enhancement that has been requested: allow multiple
>> source URLs to be moved or copied into a single destination URL,
>> i.e. make the source argument into an APR array.
Hold it. I thought a bit about extending move/copy in this way, but there is
no good, simple, generic solution. When we start talking about multiple
operations being part of the same commit, we should discuss an API that allows
multiple arbitrary operations, not just certain restricted forms of "copy" and
"move". (For example, the form suggested doesn't allow for renaming as part of
the move.) Let's leave that discussion for another time.
>>> See issue 2188 for details, but the short version is:
>>> Clients of our API want to be able to disable the implicit behaviour
>>> of "if copy destination exists and is a directory, append basename of
>>> the source to the destination" that we have now. This behaviour makes
>>> sense in some circumstances, but can prove a great annoyance in others.
[...]
>> Another trivial solution is to move the logic out of libsvn_client
>> altogether and put it in the application.
Yes.
> No, because the current API must remain compatible, so such code must
> remain in libsvn_client, so we might as well make the convenience
> available to client writers.
That is not necessarily the best approach. Yes, a copy of the logic must
remain in libsvn_client for compatibility, but we should still change the API
to whatever is best even if that means that the client has to grow another copy
of the logic.
>>> HOWEVER, I think there is a better API change:
>>>
>>> Add a new tri-state enum parameter:
>>>
>>> enum {
>>> svn_copymove_collision_error,
>>> svn_copymove_collision_make_child,
>>> svn_copymove_collision_replace
>>> };
No, that's making the API too complex. It should do one task and do it well.
Certainly the "error or replace" part is useful, but there is enough complexity
already and automatically making a child is just too much.
A sensible remit for this API is to copy (or move) an item while possibly
renaming it. Therefore it should take the source full pathname and the
destination full pathname of the item, and copy/move the one to the other. If
the parent directory of the destination does not exist, it should either error
or create all intermediate directories. If the destination exists, it should
either error or overwrite it. We could make design-time decisions on those
options, or the functions could take boolean parameters to control those options.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: API proposal - issue 2188 - svn_client_copy/move
Posted by Max Bowsher <ma...@ukf.net>.
Philip Martin wrote:
> "Max Bowsher" <ma...@ukf.net> writes:
>
>> svn_client_move has been revved to svn_client_move2 in 1.2, which
>> makes it an attractive idea to get some further planned changes to
>> this API out of the way now too.
>
> There is another enhancement that has been requested: allow multiple
> source URLs to be moved or copied into a single destination URL,
> i.e. make the source argument into an APR array.
Does it have an issue? What are the intended semantics for
existant/non-existant destinations?
>> See issue 2188 for details, but the short version is:
>> Clients of our API want to be able to disable the implicit behaviour
>> of "if copy destination exists and is a directory, append basename of
>> the source to the destination" that we have now. This behaviour makes
>> sense in some circumstances, but can prove a great annoyance in others.
>>
>> So, the initial obvious solution is trivial - a new boolean parameter.
>
> Another trivial solution is to move the logic out of libsvn_client
> altogether and put it in the application.
No, because the current API must remain compatible, so such code must remain
in libsvn_client, so we might as well make the convenience available to
client writers.
>> HOWEVER, I think there is a better API change:
>>
>> Add a new tri-state enum parameter:
>>
>> enum {
>> svn_copymove_collision_error,
>> svn_copymove_collision_make_child,
>> svn_copymove_collision_replace
>> };
>>
>> To illustrate, file:///repos/A and file:///repos/B are two directories
>> that exist:
>>
>>
>> svn_copymove_collision_error:
>> svn cp file:///repos/A file:///repos/B
>> - causes error.
>>
>> svn_copymove_collision_make_child:
>> svn cp file:///repos/A file:///repos/B
>> - copies A to file:///repos/B/A
>>
>> svn_copymove_collision_replace:
>> svn cp file:///repos/A file:///repos/B
>> - is equivalent to:
>> svn rm file:///repos/B
>> svn cp file:///repos/A file:///repos/B
>> except that it uses only 1 revision number.
>>
>>
>> I am particularly interested in this, because I have seen emails from
>> quite a few disappointed users wanting to "move a tag" in just 1
>> revision, instead of the 2-stage process which is the only workaround
>> now (rm, cp).
>
> I wanted to something like that earlier this year, I wrote a program
> to do it. My program bypasses libsvn_client and drives an RA commit
> editor directly to combine multiple mv, cp and rm commands on URLs
> into a single commit.
Indeed, but most people won't be so ingenious.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: API proposal - issue 2188 - svn_client_copy/move
Posted by Philip Martin <ph...@codematters.co.uk>.
"Max Bowsher" <ma...@ukf.net> writes:
> svn_client_move has been revved to svn_client_move2 in 1.2, which
> makes it an attractive idea to get some further planned changes to
> this API out of the way now too.
There is another enhancement that has been requested: allow multiple
source URLs to be moved or copied into a single destination URL,
i.e. make the source argument into an APR array.
> See issue 2188 for details, but the short version is:
> Clients of our API want to be able to disable the implicit behaviour
> of "if copy destination exists and is a directory, append basename of
> the source to the destination" that we have now. This behaviour makes
> sense in some circumstances, but can prove a great annoyance in others.
>
> So, the initial obvious solution is trivial - a new boolean parameter.
Another trivial solution is to move the logic out of libsvn_client
altogether and put it in the application.
> HOWEVER, I think there is a better API change:
>
> Add a new tri-state enum parameter:
>
> enum {
> svn_copymove_collision_error,
> svn_copymove_collision_make_child,
> svn_copymove_collision_replace
> };
>
> To illustrate, file:///repos/A and file:///repos/B are two directories
> that exist:
>
>
> svn_copymove_collision_error:
> svn cp file:///repos/A file:///repos/B
> - causes error.
>
> svn_copymove_collision_make_child:
> svn cp file:///repos/A file:///repos/B
> - copies A to file:///repos/B/A
>
> svn_copymove_collision_replace:
> svn cp file:///repos/A file:///repos/B
> - is equivalent to:
> svn rm file:///repos/B
> svn cp file:///repos/A file:///repos/B
> except that it uses only 1 revision number.
>
>
> I am particularly interested in this, because I have seen emails from
> quite a few disappointed users wanting to "move a tag" in just 1
> revision, instead of the 2-stage process which is the only workaround
> now (rm, cp).
I wanted to something like that earlier this year, I wrote a program
to do it. My program bypasses libsvn_client and drives an RA commit
editor directly to combine multiple mv, cp and rm commands on URLs
into a single commit.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: API proposal - issue 2188 - svn_client_copy/move
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 10/28/05, Philip Martin <ph...@codematters.co.uk> wrote:
> Once the library provides an interface with predictable behaviour the
> application can implement all the "smart" behaviour on top. Quite how
> much of the "smart" behaviour should be moved into the library is a
> hard question to answer, one reason for putting it in the library is
> that it might be possible to do things more efficiently (fewer RA
> calls) in the library than in the application.
The problem is that unless the application is ok with implementing
their behavior in terms of the libsvn_ra interface, they currently
can't implement this sort of behavior because of race conditions.
There's no higher level API that allows you to say "replace this
directory with this other directory" because in between you deleting
the first directory and copying the second one in place another commit
could have placed something there, so your new copy ends up as a
subdirectory instead of the location you wanted.
The current libsvn_client APIs just don't posses the flexability to
allow the applications to provide the "smarts" that are needed.
There's no way to say "copy this to location /foo, but if another
directory shows up there in the meantime error out", and even if we
had that, you still couldn't implement the "replace /tags/foo with a
copy of /trunk" all in one commit, it would have to be split into two
commits, and the second could potentially fail due to a race
condition..
> > If we're going to add a parameter to control this kind of behavior,
> > I'd also like to add the ability to overwrite the file/directory
> > that's present in the destination. To be really useful this should
> > also apply to copy in addition to move. This is a fairly commonly
> > requested feature (say for example if you want to have a "currently
> > installed version" tag, whenever you recreate it you have to do a
> > delete then a copy).
>
> Are these requests for an application interface, "svn cp/mv", or a
> library interface, "svn_client_copy/move"?
I've seen people ask for both a command line level interface and a
language bindings level interface, which implies that the change
should be at the libsvn_client library interface and then exposed via
the command line and bindings.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: API proposal - issue 2188 - svn_client_copy/move
Posted by Philip Martin <ph...@codematters.co.uk>.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> On 10/27/05, Madan U Sreenivasan <ma...@collab.net> wrote:
>
>> I propose a simple extra parameter - on_dir_exists to the copy and
>> move API that dictates how to handle the situation of the directory
>> existing
>> a value of
>> svn_error_if_dir_exists - does exactly that
>> svn_make_sub_dir_if_dir_exists - does exactly that
>>
>> with a default value of svn_error_if_dir_exists.
>>
>> Other problems
>> Ability to copy multiple source urls to a single destination url, when
>> implemented would need to call the copy/move API, with a on_dir_exists
>> value of svn_error_if_dir_exists and can be built around this solution.
>>
>> I'd like comments on the idea(including the variable names/values
>> etc.,)
Once the library provides an interface with predictable behaviour the
application can implement all the "smart" behaviour on top. Quite how
much of the "smart" behaviour should be moved into the library is a
hard question to answer, one reason for putting it in the library is
that it might be possible to do things more efficiently (fewer RA
calls) in the library than in the application.
> If we're going to add a parameter to control this kind of behavior,
> I'd also like to add the ability to overwrite the file/directory
> that's present in the destination. To be really useful this should
> also apply to copy in addition to move. This is a fairly commonly
> requested feature (say for example if you want to have a "currently
> installed version" tag, whenever you recreate it you have to do a
> delete then a copy).
Are these requests for an application interface, "svn cp/mv", or a
library interface, "svn_client_copy/move"?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: API proposal - issue 2188 - svn_client_copy/move
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 10/27/05, Madan U Sreenivasan <ma...@collab.net> wrote:
> I see that after a patch and rejecting it too, nobody seems to exactly
> know what is to be done regarding this. So, here am proposing what I
> think is right. Pl. feel free to criticize(and hey, dont forget to
> suggest an alternate ;) )
>
> The pain area as of now is
> - The inability to return error when the destination folder already
> exists
>
> The compatibility issue as of now is
> - svn client behavior should be retained
>
> I propose a simple extra parameter - on_dir_exists to the copy and
> move API that dictates how to handle the situation of the directory
> existing
> a value of
> svn_error_if_dir_exists - does exactly that
> svn_make_sub_dir_if_dir_exists - does exactly that
>
> with a default value of svn_error_if_dir_exists.
>
> Other problems
> Ability to copy multiple source urls to a single destination url, when
> implemented would need to call the copy/move API, with a on_dir_exists
> value of svn_error_if_dir_exists and can be built around this solution.
>
> I'd like comments on the idea(including the variable names/values
> etc.,)
If we're going to add a parameter to control this kind of behavior,
I'd also like to add the ability to overwrite the file/directory
that's present in the destination. To be really useful this should
also apply to copy in addition to move. This is a fairly commonly
requested feature (say for example if you want to have a "currently
installed version" tag, whenever you recreate it you have to do a
delete then a copy).
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: API proposal - issue 2188 - svn_client_copy/move
Posted by Julian Foad <ju...@btopenworld.com>.
Madan U Sreenivasan wrote:
>
> The pain area as of now is
> - The inability to return error when the destination folder already
> exists
> I propose a simple extra parameter - on_dir_exists to the copy and
> move API that dictates how to handle the situation of the directory
> existing
[...]
> svn_make_sub_dir_if_dir_exists - does exactly that
This is the behaviour we should never have had. It is unreasonable for a
caller not to care where the item goes, so I don't want a
"make_sub_dir_if_dir_exists" option. The only reason such an ambiguous command
is usable at the command line is because users have out-of-band knowledge of
whether the destination directory already exists.
I am working on an alternative proposal. (Basically it has the option: "If
target exists, overwrite it or error?")
Garrett Rooney wrote:
> There's no way to say "copy this to location /foo, but if another
> directory shows up there in the meantime error out", and even if we
> had that, you still couldn't implement the "replace /tags/foo with a
> copy of /trunk" all in one commit, it would have to be split into two
> commits, and the second could potentially fail due to a race
> condition..
It's fair enough to aim to provide very simple but non-primitive operations
atomically, and I would allow replacement as one such. In fact, I'll
explicitly keep it in mind as a requirement for this API.
We shouldn't aim in the API to provide more complex operations such as the
above-mentioned existing behaviour "if the destination is a directory, copy
INTO it, otherwise copy TO it". There are endless possible variations that
could be wanted, and our client-level APIs are just not designed for doing them
atomically. One would have to use a transaction-oriented API
(start-transaction, do-this, do-that, end-transaction) instead.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: API proposal - issue 2188 - svn_client_copy/move
Posted by Jim Blandy <ji...@red-bean.com>.
On 11/9/05, Julian Foad <ju...@btopenworld.com> wrote:
>
> * If dest is already a dir, move src into it?
> -> No. (It is unreasonable for a caller not to know where it wants the
> destination to go. The only reason such an ambiguous command is usable at
> the
> command line is because users have out-of-band knowledge of whether the
> destination directory already exists.)
> (Differs from existing API.)
I think this is a great change. The way mv's behavior changes depending on
whether the destination exists and what type it has if it does has always
bugged me when I'm writing shell scripts where the destination isn't
something I created. You can end up doing very weird things when what you
really wanted was an error.
Using separate functions for "move into a dir" and "give this a new name,
possibly in a new directory" also lets you reflect the fact that the first
function of the pair can reasonably operate on many sources, whereas the
second doesn't, in the argument types: the first one takes an array of
sources, and the second one takes a single source.
Re: API proposal - issue 2188 - svn_client_copy/move
Posted by Julian Foad <ju...@btopenworld.com>.
Madan U Sreenivasan wrote:
>
> The pain area as of now is
> - The inability to return error when the destination folder already
> exists
Well, that's one aspect of it. The inability to be sure exactly where the item
will end up is another big problem.
Here I present my analysis of the requirements, with some details undecided.
BASIC INTERFACES
We are talking about interfaces for moving/copying a single item. Perhaps we
should consider interfaces for moving multiple items too, especially as Hyrum
Wright is currently working on it
<http://svn.haxx.se/dev/archive-2005-11/0393.shtml>, but we need not consider
that right here and now.
For a move, both the source and the destination have to be writable, and they
both have to be updated at the same time. That makes most sense when operating
either within a repository or within a WC. We could in the future extend the
support to moves from WC to repos and repos to WC, but we need not consider
that extension now.
The following three forms are therefore required, in which "path" means a full
specification for the new item, including its (possibly new) name.
* Move:
Source: item in repository (head)
Destination: path in repository (head)
* Move:
Source: versioned item in WC
Destination: path in WC
* Copy:
Source: item in repository (at a given revision) or versioned item in WC
Destination: path in repository (head) or in WC
BEHAVIOURAL OPTIONS
I mention here each of the potential variations I can think of, and decide
whether the behaviour should be fixed or optional in each respect.
* Move/copy what: file/dir/special/any item?
-> Any item.
(As existing API.)
* Change the item's name/location/both?
-> Both. (That seems reasonable when moving/copying a single item.)
(As existing API.)
* If dest is already a dir, move src into it?
-> No. (It is unreasonable for a caller not to know where it wants the
destination to go. The only reason such an ambiguous command is usable at the
command line is because users have out-of-band knowledge of whether the
destination directory already exists.)
(Differs from existing API.)
* Create parent directories if needed: yes/error?
-> Yes? Optional? (Any obstruction to creating them will result in failure:
an "overwrite destination" flag will not apply to an obstruction here.)
### Please discuss.
(Existing API: ?)
* Remove parent directories emptied by moving away the source item?
-> No. (That doesn't seem like part of this function's job.)
(As existing API.)
* If destination exists: overwrite/error?
-> Optional. We may also want this to differ depending on the types of the
existing and new items.
### Please discuss.
(This option applies only to the destination itself, not to the creation of
any parent directories in which to put it.)
(Differs from existing API.)
* With history: yes/no?
-> Yes. (I don't think we should support without-history semantics in this
API; it's complex enough already and that doesn't feel like the fundamental
meaning of "move" or "copy". An "add" interface should be used to make a new
item without history, even if the source happens to be an existing versioned
item, and even when doing so directly in the repository. This decision implies
that the source must be a versioned item. Note that this is an API spec; it
doesn't prevent a client from providing copy-without-history behaviour.)
(As existing API.)
Up to this point, I had not looked at the existing API, but now I have, and it
raises some more issues.
* Local changes in WC source: keep/discard/error?
-> Keep. (That is, move or copy them. The whole point of a working copy is
to hold one's local changes. I am amazed that the current svn_client_move3()
discards local changes if forced (is that true?), otherwise errors out. If one
wants the base version, one should specify the base version or revert the changes.)
(Differs from existing API.)
* Unversioned items in WC source (if source is a dir): keep/discard/error?
-> Move to WC: keep? Copy to repos: discard. Copy to WC: keep?
(A WC-to-repos copy (and move, if it were allowed) must inherently discard
unversioned items. Within a WC, a move should keep them because that is the
intuitive behaviour for moving a directory; the alternative name "rename" also
implies that. For a copy within a WC, I have no opinion except that
consistency with "move" would be good.)
### Please discuss.
(Differs from existing API.)
INITIAL API PROPOSAL
First I will note that the lower-level APIs such as svn_wc_copy2() may need to
be augmented to support this.
# Move a versioned item. Semantics as discussed above.
# Error if source and dest are not both in WC or both in repos.
move(source-path-or-url,
dest-path-or-url,
overwrite-dest?[, create-parents?])
-> error
# Copy a versioned item. Semantics as discussed above.
copy(source-rev, source-path-or-url,
dest-path-or-url,
overwrite-dest?[, create-parents?])
-> error
There is only one successful outcome with each of these (unlike the old API).
The options are still under discussion.
Other features of the existing API such as provisions for reporting,
authentication, log message, etc., should be retained in this new API.
With the options undecided, this looks very much like the existing API, but I
believe it was helpful to go through the design to confirm the basic form and
change some of the semantics to be more useful.
BACKWARD COMPATIBILITY
How can the existing svn_client_copy2() be implemented in terms of this new
API? I assert that we must provide an API with which that can be done. On the
other hand, I don't believe the new API needs to be such that a client can
trivially convert to using it and still get the old behaviour.
Answer: it can't be implemented atomically. It can be implemented as:
Try copy/move src-path to dest-path.
If that fails,
Try copy/move src-path to dest-path + "/" + src-name.
That can fail if an item is simultaneously being deleted at dest-path, whereas
the original would always succeed (assuming it was implemented atomically - I
haven't checked).
I believe that this is good enough. There are plenty of other scenarios in
which it would fail anyway; this just adds another with small probability.
CONCLUSION
The interface I propose here is syntactically similar to the existing one, but
has some significant semantic differences that make it more intuitive,
deterministic and useful. The implementation will require deeper changes than
had probably been anticipated.
Thoughts?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: API proposal - issue 2188 - svn_client_copy/move
Posted by Madan U Sreenivasan <ma...@collab.net>.
On Sat, 2005-04-02 at 04:21, Max Bowsher wrote:
> kfogel@collab.net wrote:
> > Given the length and complexity of this conversation, I think it would
> > be a mistake to try to get even just the API change into 1.2.
> >
> > Realistically, we can't design the API without understanding the use
> > cases and the interface anyway. But we don't want to rush those.
> > Therefore, how about having this discussion continue, but aimed toward
> > 1.3 not 1.2?
>
> I think so. It's obviously more complicated than I'd hoped.
> Kicking 2188 to 1.3.
I see that after a patch and rejecting it too, nobody seems to exactly
know what is to be done regarding this. So, here am proposing what I
think is right. Pl. feel free to criticize(and hey, dont forget to
suggest an alternate ;) )
The pain area as of now is
- The inability to return error when the destination folder already
exists
The compatibility issue as of now is
- svn client behavior should be retained
I propose a simple extra parameter - on_dir_exists to the copy and
move API that dictates how to handle the situation of the directory
existing
a value of
svn_error_if_dir_exists - does exactly that
svn_make_sub_dir_if_dir_exists - does exactly that
with a default value of svn_error_if_dir_exists.
Other problems
Ability to copy multiple source urls to a single destination url, when
implemented would need to call the copy/move API, with a on_dir_exists
value of svn_error_if_dir_exists and can be built around this solution.
I'd like comments on the idea(including the variable names/values
etc.,)
Regards,
Madan.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: API proposal - issue 2188 - svn_client_copy/move
Posted by Max Bowsher <ma...@ukf.net>.
kfogel@collab.net wrote:
> Given the length and complexity of this conversation, I think it would
> be a mistake to try to get even just the API change into 1.2.
>
> Realistically, we can't design the API without understanding the use
> cases and the interface anyway. But we don't want to rush those.
> Therefore, how about having this discussion continue, but aimed toward
> 1.3 not 1.2?
I think so. It's obviously more complicated than I'd hoped.
Kicking 2188 to 1.3.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: API proposal - issue 2188 - svn_client_copy/move
Posted by kf...@collab.net.
Given the length and complexity of this conversation, I think it would
be a mistake to try to get even just the API change into 1.2.
Realistically, we can't design the API without understanding the use
cases and the interface anyway. But we don't want to rush those.
Therefore, how about having this discussion continue, but aimed toward
1.3 not 1.2?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org