trunk client fails during conflict resolution

[Alexey Neyman <st...@att.net>]

Hi,

Some time ago, in a separate email thread I was asked to try 1.10 
client. I have been using it since, and today it showed an error during 
merge:

Checking r12300... done
Tree conflict on '<dir>':
Directory merged from
'^/trunk/<dir>@12172'
to
'^/trunk/<dir>@12414'
was deleted by <user> in r12300.
A directory which differs from the corresponding directory on the merge 
source branch was found in the working copy.
Select: (p) postpone, (r) accept current working copy state,
         (i) ignore incoming deletion, (a) accept incoming deletion,
         (h) help, (q) quit resolution: a
svn: warning: apr_err=SVN_ERR_WC_NOT_LOCKED
svn: warning: W155005: No write-lock in 
'/home/aneyman/work/merge-shmem/lynxsecure/src/rif'
subversion/svn/merge-cmd.c:551,
subversion/svn/resolve-cmd.c:473: 
(apr_err=SVN_ERR_WC_CONFLICT_RESOLVER_FAILURE)
svn: E155027: Failure occurred resolving one or more conflicts

Using svn compiled from r1763039.

What happened: while 'svn merge' was waiting for response, I decided to 
find out if I had any local changes in the offending directory. In a 
separate shell, I ran 'svn log --stop-on-copy <dir>' and then 'svn diff 
-c REV <dir>', where REV is the revision reported by 'svn log' on that 
directory. After that, I accepted incoming deletion, but the client 
aborted the merge - see above.

On a separate note, the only revision reported on that directory by 'svn 
log' was a previous merge from ^/trunk. I am not sure how it made the 
^/mybranch/<dir> different from ^/trunk/<dir> - IMO, they should've been 
identical. It would be helpful if 'svn merge' offered a verbose view on 
what it deemed different.

Regards,
Alexey.

Re: trunk client fails during conflict resolution

[Stefan Sperling <st...@elego.de>]

On Tue, Oct 18, 2016 at 04:36:27PM -0700, Alexey Neyman wrote:
> On 10/18/2016 02:02 PM, Stefan Sperling wrote:
> > On Tue, Oct 18, 2016 at 01:42:40PM -0700, Alexey Neyman wrote:
> > > I just found what made it consider this directory different: it had build
> > > artifacts (*.o, *.d, etc) in that directory - once I ran 'make clean' prior
> > > to merge, the merge proceeded smoothly. Does the client consider unversioned
> > > files when comparing the directories?
> > I could reproduce this with unversioned artifacts in the directory and
> > without. It seems accepting the deletion of a directoy was broken in
> > general. The change I just committed in r1765506 fixes the problem here
> > Can you confirm?
> Yes, directory deletion is accepted if I choose (a) and merge completes
> successfully.
> 
> My point of mentioning the build artifacts was that without build artifact
> there is no conflict to begin with. So the question was, why does a presence
> of unversioned files in <dir> affect the tree conflict detection?
> 
> Regards,
> Alexey.

Ah, I see what you mean now.
Well, that's a matter of continous debate. Some developers think it should,
and some don't. Some times detection was implemented one way or the other.
I think that's a problem but it's not a high priority one.

Re: trunk client fails during conflict resolution

[Alexey Neyman <st...@att.net>]

On 10/18/2016 02:02 PM, Stefan Sperling wrote:
> On Tue, Oct 18, 2016 at 01:42:40PM -0700, Alexey Neyman wrote:
>> I just found what made it consider this directory different: it had build
>> artifacts (*.o, *.d, etc) in that directory - once I ran 'make clean' prior
>> to merge, the merge proceeded smoothly. Does the client consider unversioned
>> files when comparing the directories?
> I could reproduce this with unversioned artifacts in the directory and
> without. It seems accepting the deletion of a directoy was broken in
> general. The change I just committed in r1765506 fixes the problem here
> Can you confirm?
Yes, directory deletion is accepted if I choose (a) and merge completes 
successfully.

My point of mentioning the build artifacts was that without build 
artifact there is no conflict to begin with. So the question was, why 
does a presence of unversioned files in <dir> affect the tree conflict 
detection?

Regards,
Alexey.

Re: trunk client fails during conflict resolution

[Stefan Sperling <st...@elego.de>]

On Tue, Oct 18, 2016 at 01:42:40PM -0700, Alexey Neyman wrote:
> I just found what made it consider this directory different: it had build
> artifacts (*.o, *.d, etc) in that directory - once I ran 'make clean' prior
> to merge, the merge proceeded smoothly. Does the client consider unversioned
> files when comparing the directories?

I could reproduce this with unversioned artifacts in the directory and
without. It seems accepting the deletion of a directoy was broken in
general. The change I just committed in r1765506 fixes the problem here.
Can you confirm?

Thank you!

Re: trunk client fails during conflict resolution

[Alexey Neyman <st...@att.net>]

On 10/18/2016 01:38 PM, Alexey Neyman wrote:
> Hi,
>
> Some time ago, in a separate email thread I was asked to try 1.10 
> client. I have been using it since, and today it showed an error 
> during merge:
>
> Checking r12300... done
> Tree conflict on '<dir>':
> Directory merged from
> '^/trunk/<dir>@12172'
> to
> '^/trunk/<dir>@12414'
> was deleted by <user> in r12300.
> A directory which differs from the corresponding directory on the 
> merge source branch was found in the working copy.
> Select: (p) postpone, (r) accept current working copy state,
>         (i) ignore incoming deletion, (a) accept incoming deletion,
>         (h) help, (q) quit resolution: a
> svn: warning: apr_err=SVN_ERR_WC_NOT_LOCKED
> svn: warning: W155005: No write-lock in 
> '/home/aneyman/work/merge-shmem/lynxsecure/src/rif'
> subversion/svn/merge-cmd.c:551,
> subversion/svn/resolve-cmd.c:473: 
> (apr_err=SVN_ERR_WC_CONFLICT_RESOLVER_FAILURE)
> svn: E155027: Failure occurred resolving one or more conflicts
>
> Using svn compiled from r1763039.
>
> What happened: while 'svn merge' was waiting for response, I decided 
> to find out if I had any local changes in the offending directory. In 
> a separate shell, I ran 'svn log --stop-on-copy <dir>' and then 'svn 
> diff -c REV <dir>', where REV is the revision reported by 'svn log' on 
> that directory. After that, I accepted incoming deletion, but the 
> client aborted the merge - see above.
>
> On a separate note, the only revision reported on that directory by 
> 'svn log' was a previous merge from ^/trunk. I am not sure how it made 
> the ^/mybranch/<dir> different from ^/trunk/<dir> - IMO, they 
> should've been identical. It would be helpful if 'svn merge' offered a 
> verbose view on what it deemed different.

I just found what made it consider this directory different: it had 
build artifacts (*.o, *.d, etc) in that directory - once I ran 'make 
clean' prior to merge, the merge proceeded smoothly. Does the client 
consider unversioned files when comparing the directories?

Regards,
Alexedy.