Re: [PATCH] Moving/copying added files and dirs

On 8/9/06, Paul Burba <paulb@softlanding.com> wrote:
>
> Hi All,
>
> Just to be clear on my goal in this chunk of code: it's to determine if
> the src_path arg to setup_copy is scheduled for addition as a result of
> svn add, as opposed to a WC->WC copy/move. We need to know this since
> wc_to_wc_copy() handles these two cases differently. My comment is
> unclear on this and I will improve it with something like this:
>
[..]
> So we can't just look at the schedule value, it's add in both cases. The
> explanation of the revision field in
> http://svn.collab.net/repos/svn/trunk/subversion/libsvn_wc/README is:
>
> revision:
> The revision that the pristine text and properties of this entry
> represent. Defaults to the revision of the this_dir entry, for
> which it is required. Set to 0 for entries not yet in the
> repository.
>
> Between this and the observed behavior above led me to think that looking
> at the rev is the way to differentiate between the two scenarios. The
> docstring for svn_wc_add2() makes no promises regarding the revision of
> added paths, though it does explicitly set it to 0 on line 1184:
>
> tmp_entry.revision = 0;
>
> Maybe I'm making a dangerous assumption?
>
> Perhaps it's better to look at the schedule *and* copy fields to make the
> determination?
>
> if (!src_is_url)
> {
> /* Are we copying/moving a path that is scheduled for addition
> as the result of svn add or svn mv/cp? */
> SVN_ERR(svn_wc_adm_probe_open3(&adm_access, NULL, src_path, FALSE,
> 0,
> ctx->cancel_func, ctx->cancel_baton,
> pool));
> SVN_ERR(svn_wc_entry(&entry, src_path, adm_access, FALSE, pool));
> SVN_ERR(svn_wc_adm_close(adm_access));
> /* If scheduled for addition but not copied, src_path is
> result of svn add not svn cp/mv. */
> src_is_add = (entry
> && entry->schedule == svn_wc_schedule_add
> && !(entry->copied))
> ? TRUE : FALSE;
> }
>
> Thoughts?
>
I consider that anyway condition should be the same that in
copy_file_administratively() and copy_dir_administratively() But have
same condition in several place is little bit dangerous,
so might we should reconsider and move your code from libsvn_client to
libsvn_wc?

On 8/9/06, Paul Burba <paulb@softlanding.com> wrote:
> Notice none of the unversioned children of H get moved, while only A\D\I
> gets copied.
>
> Also, a related oddity: While svn copy normally copies these first
> generation unversioned children, svn move requires you to use --force and
> then it *deletes* all the unversioned items in the source and does *not*
> copy any of them...so much for "this subcommand is equivalent to a 'copy'
> and 'delete'."
>
You are not right, they copied, but doesn't displayed in svn st -v.
Just check directory D_move\I by hand.

-- 
Ivan Zhakov
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org