[PATCH] Moving/copying added files and dirs

Paul Burba <paulb@softlanding.com> wrote on 07/27/2006 08:37:31 AM:

> Ivan,
>
> Sorry, I wasn't able to look at this until yesterday afternoon. I'm
> afraid it's not as simple as defeating sanity check 2 (i.e. in
> copy_file_administratively(): /* Sanity check 2: You cannot make a copy
of
> something that's not in the repository unless it's a copy of an
> uncommitted copy. */). Here are some of the problems I see:
>
> 1) An added file has no text base, so when copy_file_administratively()
> tries to copy the pristine text base it fails.
>
> 2) If we are going to support copying an added file, it only makes sense

> (?) to support the following as well:
>
> a) moving an added file
> b) copying an added directory
> c) moving an added directory
>
> This isn't so much a problem, as an added complication.
>
> 3) If we move an added file how do we get rid of the add entry in the
> source directory? It's not like moving a versioned item, we don't want
> any evidence left behind in entries that something once existed there
and
> was scheduled for addition...do we? I suppose the equivalent of svn rm
> --force will work...
>
> Anyhow, I'm looking into this right now, hope to have some ideas
shortly.

...and here here it is. This patch supports copying and moving of added
paths within a WC or from a WC to the REPOS.

Re issue 1 above, after looking at this I think the solution shouldn't
reside in libsvn_wc, but rather in libsvn_client. Trying to teach
svn_wc_copy2() to copy paths that are not versioned doesn't make a lot of
sense. It seems all we really need to do is copy the added files without
the administrative directories and then add them. The first task sounds
an awful lot like an export, and with some borrowed/modified code from
copy_versioned_files() in export.c that's what this patch does. Then a
call to svn_client_add3() adds the copied files. Does this approach sound
reasonable?

Also, there is one obvious oddity regarding my solution, that is the
notification of 'A'dded 'D'eleted paths. Normally svn copy reports 'A'dds
first then 'D'eletes, but this patch reports in the opposite order when
moving/copying an added path (i.e. the Deletes are reported first). It's
certainly possible to make tweak wc_to_wc_copy() to make the ordering the
same, but it would require a bit more cumbersome logic and require
svn_wc_adm_access_t *adm_access/src_access to be opened and closed twice,
and I wasn't sure this is worth it(?).

Let me know your thoughts,

Paul B.

[[[
Support copy and move of paths scheduled for addition.

Follow-up to r20811.

Suggested by: zhakov

* subversion/libsvn_client/copy.c
  (svn_pools.h): Include.
  (copy_added_path): Helper function for wc_to_wc_copy() which copies
  paths scheduled for addition to a new WC location.
  (wc_to_wc_copy): Add new argument indicating if src_path is not under
  version control but is scheduled for addition. Use copy_added_path()
  rather than svn_wc_copy2() when copying added paths, then add these
  with svn_client_add3().
  (setup_copy): Determine if we are copying a path that is scheduled
  for addition by looking at it's revision and pass that info to
  wc_to_wc_copy().

* subversion/tests/cmdline/copy_tests.py
  (copy_move_added_paths, copy_added_paths_to_URL): New tests.
  (test_list): Run new tests.
]]]

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