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."
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
Received on 2011-06-07 13:45:46 CEST