You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by sb...@apache.org on 2011/06/07 01:27:07 UTC
svn commit: r1132834 - in /subversion/trunk/subversion: libsvn_client/copy.c
libsvn_wc/adm_ops.c tests/cmdline/copy_tests.py
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.
Modified:
subversion/trunk/subversion/libsvn_client/copy.c
subversion/trunk/subversion/libsvn_wc/adm_ops.c
subversion/trunk/subversion/tests/cmdline/copy_tests.py
Modified: subversion/trunk/subversion/libsvn_client/copy.c
URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_client/copy.c?rev=1132834&r1=1132833&r2=1132834&view=diff
==============================================================================
--- subversion/trunk/subversion/libsvn_client/copy.c (original)
+++ subversion/trunk/subversion/libsvn_client/copy.c Mon Jun 6 23:27:06 2011
@@ -335,20 +335,14 @@ do_wc_to_wc_moves_with_locks2(void *bato
scratch_pool);
SVN_ERR(svn_wc_copy3(b->ctx->wc_ctx, b->pair->src_abspath_or_url,
- dst_abspath, TRUE /* metadata_only */,
+ dst_abspath, FALSE /* metadata_only */,
b->ctx->cancel_func, b->ctx->cancel_baton,
b->ctx->notify_func2, b->ctx->notify_baton2,
scratch_pool));
- /* Should we be using a workqueue for this move? It's not clear.
- What should happen if the copy above is interrupted? The user
- may want to abort the move and a workqueue might interfere with
- that. */
- SVN_ERR(svn_io_file_rename(b->pair->src_abspath_or_url, dst_abspath,
- scratch_pool));
-
SVN_ERR(svn_wc_delete4(b->ctx->wc_ctx, b->pair->src_abspath_or_url,
- TRUE, FALSE,
+ FALSE /* keep_local */,
+ FALSE /* delete_unversioned_target */,
b->ctx->cancel_func, b->ctx->cancel_baton,
b->ctx->notify_func2, b->ctx->notify_baton2,
scratch_pool));
Modified: subversion/trunk/subversion/libsvn_wc/adm_ops.c
URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/adm_ops.c?rev=1132834&r1=1132833&r2=1132834&view=diff
==============================================================================
--- subversion/trunk/subversion/libsvn_wc/adm_ops.c (original)
+++ subversion/trunk/subversion/libsvn_wc/adm_ops.c Mon Jun 6 23:27:06 2011
@@ -593,6 +593,24 @@ erase_unversioned_from_wc(const char *pa
return SVN_NO_ERROR;
}
+/* Delete the file FILE_ABSPATH if it exists. */
+static svn_error_t *
+attempt_deletion(const char *file_abspath,
+ apr_pool_t *scratch_pool)
+{
+ svn_error_t *err;
+
+ if (file_abspath == NULL)
+ return SVN_NO_ERROR;
+
+ err = svn_io_remove_file2(file_abspath, FALSE, scratch_pool);
+
+ if (err == NULL || !APR_STATUS_IS_ENOENT(err->apr_err))
+ return svn_error_return(err);
+
+ svn_error_clear(err);
+ return SVN_NO_ERROR;
+}
svn_error_t *
svn_wc_delete4(svn_wc_context_t *wc_ctx,
@@ -609,11 +627,12 @@ svn_wc_delete4(svn_wc_context_t *wc_ctx,
svn_error_t *err;
svn_wc__db_status_t status;
svn_wc__db_kind_t kind;
+ svn_boolean_t conflicted;
err = svn_wc__db_read_info(&status, &kind, NULL, NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
- NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
- NULL, NULL, NULL, NULL,
+ NULL, NULL, NULL, NULL, NULL, &conflicted, NULL,
+ NULL, NULL, NULL, NULL, NULL,
db, local_abspath, pool, pool);
if (delete_unversioned_target &&
@@ -662,6 +681,36 @@ svn_wc_delete4(svn_wc_context_t *wc_ctx,
SVN_ERR(svn_wc__write_check(db, svn_dirent_dirname(local_abspath, pool),
pool));
+ if (!keep_local &&
+ conflicted &&
+ kind == svn_wc__db_kind_file)
+ {
+ const apr_array_header_t *conflicts;
+ int i;
+
+ /* Does the file have any unversioned conflict marker files? */
+ SVN_ERR(svn_wc__db_read_conflicts(&conflicts, db, local_abspath,
+ pool, pool));
+
+ for (i = 0; i < conflicts->nelts; i++)
+ {
+ const svn_wc_conflict_description2_t *desc;
+
+ desc = APR_ARRAY_IDX(conflicts, i,
+ const svn_wc_conflict_description2_t*);
+
+ if (desc->kind == svn_wc_conflict_kind_text)
+ {
+ attempt_deletion(desc->base_abspath, pool);
+ attempt_deletion(desc->their_abspath, pool);
+ attempt_deletion(desc->my_abspath, pool);
+ }
+ else if (desc->kind == svn_wc_conflict_kind_property)
+ attempt_deletion(desc->their_abspath, pool);
+ }
+
+ }
+
SVN_ERR(svn_wc__db_op_delete(db, local_abspath,
notify_func, notify_baton,
cancel_func, cancel_baton,
Modified: subversion/trunk/subversion/tests/cmdline/copy_tests.py
URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/tests/cmdline/copy_tests.py?rev=1132834&r1=1132833&r2=1132834&view=diff
==============================================================================
--- subversion/trunk/subversion/tests/cmdline/copy_tests.py (original)
+++ subversion/trunk/subversion/tests/cmdline/copy_tests.py Mon Jun 6 23:27:06 2011
@@ -5222,11 +5222,11 @@ def case_only_rename(sbox):
svntest.actions.run_and_verify_status(wc_dir, expected_status)
@Issue(3899)
-def copying_conflicts(sbox):
- """copying conflicts"""
+def copy_and_move_conflicts(sbox):
+ """copy and move conflicts"""
- # The destination of a copy operation should *not* be conflicted,
- # and should contain the "mine-full" contents.
+ # The destination of a copy or move operation should *not* be
+ # conflicted, and should contain the "mine-full" contents.
sbox.build()
wc = sbox.ospath
@@ -5392,6 +5392,54 @@ def copying_conflicts(sbox):
})
svntest.actions.verify_disk(wc('copy-dest'), expected_disk, True)
+ # Move conflict victims.
+ sbox.simple_move('A/B/E/alpha', 'move-dest')
+ sbox.simple_move('A/D/H', 'move-dest')
+ sbox.simple_move('A/D/G', 'move-dest')
+ sbox.simple_move('A/Q', 'move-dest')
+
+ # Move directories with conflicted children.
+ sbox.simple_move('A/B', 'move-dest')
+ sbox.simple_move('A/D', 'move-dest')
+
+ # Expect same status and disk content as at the copy destination, except
+ # that A/B/E/alpha, A/D/G, and A/D/H were moved away first.
+ expected_status.wc_dir = wc('move-dest')
+ expected_status.tweak('B/E/alpha',
+ 'D/H',
+ 'D/H/chi',
+ 'D/H/omega',
+ 'D/H/psi',
+ status='D ')
+ # A/D/G had been re-added from r4 due to a "local edit, incoming delete"
+ # tree conflict, so moving it away has a different effect.
+ expected_status.remove('D/G',
+ 'D/G/pi',
+ 'D/G/rho',
+ 'D/G/tau')
+ svntest.actions.run_and_verify_status(wc('move-dest'), expected_status)
+
+ expected_disk = svntest.wc.State('', {
+ 'B/E/beta' : Item(contents="This is the file 'beta'.\n"
+ "Edit for merge\n"),
+ 'B/lambda' : Item(contents="This is the file 'lambda'.\n"),
+ 'B/F' : Item(),
+ 'H' : Item(props={'foo':'100'}),
+ 'H/chi' : Item(contents="This is the file 'chi'.\n",
+ props={'foo':'100'}),
+ 'H/psi' : Item(contents="This is the file 'psi'.\n"),
+ 'H/omega' : Item(contents="This is the file 'omega'.\n"),
+ 'D' : Item(),
+ 'G/tau' : Item(contents="This is the file 'tau'.\n"),
+ 'G/rho' : Item(contents="This is the file 'rho'.\n"
+ "Local edit\n"),
+ 'G/pi' : Item(contents="This is the file 'pi'.\n"),
+ 'Q/sigma' : Item(contents="New local file\n"),
+ 'alpha' : Item(contents="This is the file 'alpha'.\n"
+ "Local edit\n"),
+ })
+ svntest.actions.verify_disk(wc('move-dest'), expected_disk, True)
+
########################################################################
# Run the tests
@@ -5501,7 +5549,7 @@ test_list = [ None,
deleted_file_with_case_clash,
copy_base_of_deleted,
case_only_rename,
- copying_conflicts,
+ copy_and_move_conflicts,
]
if __name__ == '__main__':
RE: svn commit: r1132834 - in /subversion/trunk/subversion: libsvn_client/copy.c libsvn_wc/adm_ops.c tests/cmdline/copy_tests.py
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Stephen Butler [mailto:sbutler@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
Re: svn commit: r1132834 - in /subversion/trunk/subversion: libsvn_client/copy.c libsvn_wc/adm_ops.c tests/cmdline/copy_tests.py
Posted by Stephen Butler <sb...@elego.de>.
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
RE: svn commit: r1132834 - in /subversion/trunk/subversion: libsvn_client/copy.c libsvn_wc/adm_ops.c tests/cmdline/copy_tests.py
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Stephen Butler [mailto:sbutler@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
>
Re: svn commit: r1132834 - in /subversion/trunk/subversion: libsvn_client/copy.c libsvn_wc/adm_ops.c tests/cmdline/copy_tests.py
Posted by Stephen Butler <sb...@elego.de>.
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().
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?
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.
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
Re: svn commit: r1132834 - in /subversion/trunk/subversion: libsvn_client/copy.c libsvn_wc/adm_ops.c tests/cmdline/copy_tests.py
Posted by Stephen Butler <sb...@elego.de>.
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 r1061328.
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
RE: svn commit: r1132834 - in /subversion/trunk/subversion: libsvn_client/copy.c libsvn_wc/adm_ops.c tests/cmdline/copy_tests.py
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Bert Huijben [mailto:bert@qqmail.nl]
> Sent: dinsdag 7 juni 2011 1:58
> To: sbutler@apache.org
> Cc: dev@subversion.apache.org
> Subject: RE: svn commit: r1132834 - in /subversion/trunk/subversion:
> libsvn_client/copy.c libsvn_wc/adm_ops.c tests/cmdline/copy_tests.py
>
>
>
> > -----Original Message-----
> > From: sbutler@apache.org [mailto:sbutler@apache.org]
> > Sent: dinsdag 7 juni 2011 1:27
> > To: commits@subversion.apache.org
> > Subject: svn commit: r1132834 - in /subversion/trunk/subversion:
> > libsvn_client/copy.c libsvn_wc/adm_ops.c tests/cmdline/copy_tests.py
> >
> > 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?
At least one test FAILED, checking E:\w2k3\tests\tests.log
FAIL: op-depth-test.exe 23: test_case_rename on case (in)sensitive system
FAIL: copy_tests.py 102: case-only rename
Summary of test results:
>
> Bert
RE: svn commit: r1132834 - in /subversion/trunk/subversion: libsvn_client/copy.c libsvn_wc/adm_ops.c tests/cmdline/copy_tests.py
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: sbutler@apache.org [mailto:sbutler@apache.org]
> Sent: dinsdag 7 juni 2011 1:27
> To: commits@subversion.apache.org
> Subject: svn commit: r1132834 - in /subversion/trunk/subversion:
> libsvn_client/copy.c libsvn_wc/adm_ops.c tests/cmdline/copy_tests.py
>
> 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.
I think you need to find a better way to fix this very specific issue.
Bert