David Glasser wrote:
> On 11/23/06, hwright@tigris.org <hwright@tigris.org> wrote:
>> Log:
>> Stub out the svn_client_*_into APIs, but don't change the underlying
>> functionality, just truncate src_paths argument when performing the copy
>> or move.
>
> For what it's worth, it's probably worth mentioning that it's a stub
> in a comment in addition to the log message (even though this is a
> private branch).
Done.
>> /**
>> + * Copy all @a src_paths into @a dst_dir.
>> + *
>> + * Use the same semantics as svn_client_copy3(), but with the following
>> + * changes:
>
> I'm not sure that it does use the same semantics, since copy3 doesn't
> automatically put things into directories (unlike copy2). Though
> maybe that's not what you're getting at.
I basically got a little lazy and didn't copy the svn_client_copy3()
documentation. I plan on revisiting the documentation when we iron out
the atomicity rules (below).
>> +/**
>> + * Move all @a src_paths into @a dst_dir.
>> + *
>> + * Each one of @a src_paths must be a file or directory under version
>> + * control, or the URL of a versioned item in the repository. They
>> + * must also all be of the same type, e.g., all URLs or all WC paths.
>> + *
>> + * @a dst_path must be a directory.
>
> You mean dst_dir.
Done.
>> + return setup_copy(commit_info_p, src_path, src_revision, dst_path,
>> + FALSE /* is_move */,
>> + TRUE /* force, set to avoid deletion check */,
>
> I don't get why you need that force, but I'll leave this nit until the
> actual implementation is written :-)
I stole that from svn_client_copy3(). I haven't looked into exactly why
the copy functions need to use force.
> The main question I think when I see these new APIs, which is only
> partially addressed by your documentation, is what amount of atomicity
> will occur. I suppose that for ->repo operations it'll clearly be
> atomic since it's a commit; how about for ->wc operations? Will
> failure result in some copies having occured and others not occuring?
> If there's an error, will the ones afterwards still be attempted?
>
> (I'm not sure what the right answers to these questions are, both in
> terms of useful API design and implementability.)
All good questions. When performing a multiple local add, we keep
adding, even if we encounter an error with a previous file. I believe
my multiple move and copy implementation does the same thing, although
it needs be tested more thoroughly. ->repo operations are atomic.
I'll update the documentation to reflect the above, but I also wonder if
it is correct. What should the behavior be for a ->wc operation which
fails on some files but not all? Should `svn add' be modified to check
addability before performing the add and fail if some of the files can't
be added?
Whatever the answers are, we should be consistent across all svn
commands, not just `copy' and `move'.
-Hyrum
Received on Fri Nov 24 20:34:40 2006