> -----Original Message-----
> From: Stephen Butler [mailto:sbutler_at_elego.de]
> Sent: dinsdag 7 juni 2011 13:45
> To: Bert Huijben
> Cc: '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 12:56 , Bert Huijben 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).
>
> [...]
>
> >>>>>
> >>>>> 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.
>
> I agree, your solution is much better.
>
> >
> >> 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
>
> The 1.6 behavior is inconsistent.
>
> - Most conflicts are copied as-is. I think consensus is that that's a
bad idea.
>
> - Some are are copied, but leave behind the marker file explaining the
> conflict (e.g., copying a single prop-conflicted file).
>
> - Some are resolved, but have conflict-markers in text (e.g., copying a
> single text-conflicted file).
>
> - Some aren't copied at all (e.g., "local missing" merge conflicts).
That's OK.
>
> For 1.7, I'd like to have a rule that we can explain in a single sentence:
>
> "Copying conflicted items implies 'svn resolve --depth infinite --accept
> mine-full' at the destination path."
Yes, agreed, this is easy to explain.
But I see two small problems with this explanation that you wouldn't have
with
svn resove --depth infinite --accept working
* For text conflicts the working file contains the information from both
versions, so you don't lose any information by copying/moving.
(For binary conflicts the working file is the mine file). You might even
lose the file where you already resolved some of the conflicts yourself.
* For tree conflicts --accept mine-full is still undefined.
'mine-full' completely ignores theirs even when there is only one small
conflict in a huge change, and I don't think that is a safe default.
Bert
Received on 2011-06-07 15:04:00 CEST