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
