> -----Original Message-----
> From: Stephen Butler [mailto:sbut...@elego.de]
> Sent: dinsdag 7 juni 2011 2:49
> To: Stephen Butler
> Cc: Bert Huijben; Subversion Development
> Subject: Re: svn commit: r1132834 - in /subversion/trunk/subversion:
> libsvn_client/copy.c libsvn_wc/adm_ops.c tests/cmdline/copy_tests.py
>
>
> On Jun 7, 2011, at 2:22 , Stephen Butler wrote:
>
> >
> > On Jun 7, 2011, at 2:02 , Bert Huijben wrote:
> >
> > [...]
> >
> >>>> Author: sbutler
> >>>> Date: Mon Jun 6 23:27:06 2011
> >>>> New Revision: 1132834
> >>>>
> >>>> URL: http://svn.apache.org/viewvc?rev=1132834&view=rev
> >>>> Log:
> >>>> Fix the move command for issue 3899 (auto resolve for wc-wc
> >>>> copies/moves).
> >>>>
> >>>> * subversion/tests/cmdline/copy_tests.py
> >>>> (copying_conflicts): Rename to...
> >>>> (copy_and_move_conflicts): ...this and add test cases for moves.
> >>>>
> >>>> * subversion/libsvn_client/copy.c
> >>>> (do_wc_to_wc_moves_with_locks2): Let svn_wc_copy3() copy the
> items
> >>>> and
> >>>> let svn_wc_delete4() delete them. This reverts r1061328.
> >>>>
> >>>> * subversion/libsvn_wc/adm_ops.c
> >>>> (attempt_deletion): New function.
> >>>> (svn_wc_delete4): If a file has unresolved text or property
conflicts,
> >>>> delete conflict marker files.
> >>>
> >>> This breaks case only renames on case insensitive filesystems and
makes
> svn
> >>> move *much* *much* *much* slower, by making a copy of everything
> from
> >>> what used to be a simple administrative change.
> >> (and a rename)
> >>
> >>>
> >>> I think you need to find a better way to fix this very specific issue.
> >>
> >> Can you please revert this change until we have a better fix, to fix
the
> renaming issue?
> >
> > I reverted that revision except for the test changes (now XFAIL).
> >
> > I'll try again with a quick hack in the spirit of r106132.
>
> Hmmm, it's not so easy. The problem is in libsvn_client, but there's no
> libsvn_wc API to fix it, except for svn_wc_copy3().
I think I added the necessary plumbing in r1132919, r1132924 and r1132948.
> If svn_wc_copy3() is such a dog in the local-copy case, then maybe we
> should rewrite it to take advantage of WC-NG. Any takers?
It already uses wc-ng (but can certainly be optimized further)
The problem with your version of the code was that it changed the value of
the metadata_only argument from TRUE to FALSE.
So instead of just changing wc_db and performing a single
svn_io_file_rename() on the move target all the actual files were copied.
(And then the originals deleted)
So instead of doing a single io-operation, we were reading and writing all
the on-disk data.
> Anyway, most of the issue has been resolved already. There's just the
> minor matter of useless conflict marker files sometimes being moved
> along with the intended items.
I think I fixed that part in those patches. That just leaves the question:
Which file should we leave after the copy?
I'm +0.5 on leaving the WORKING file, instead of replacing it with MINE.
This should match the 'svn copy behavior', maybe follow how we did it in
<=1.6 and above all make sense.
So I leave it to you to make a sensible decision here ;-)
Bert
>
> Steve
>
> --
> Stephen Butler | Senior Consultant
> elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
> tel: +49 30 2345 8696 | mobile: +49 163 25 45 015
> fax: +49 30 2345 8695 | http://www.elegosoft.com
> Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
> Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
