On 01/19/2011 03:17 AM, Daniel Becroft wrote:
On Wed, Jan 19, 2011 at 7:36 AM, Daniel Shahaf <d...@daniel.shahaf.name
<mailto:d...@daniel.shahaf.name>> wrote:
Daniel Becroft wrote on Wed, Jan 19, 2011 at 07:27:15 +1000:
> On Wed, Jan 19, 2011 at 3:08 AM, Daniel Shahaf
<d...@daniel.shahaf.name <mailto:d...@daniel.shahaf.name>>wrote:
> > Daniel Becroft wrote on Tue, Jan 18, 2011 at 07:13:12 +1000:
> > > 2) The problem also exists under the '--reintegrate'
scenario, even
> > > after a subsequent commit. Would it be better to include that
case
> > > here, or move the entire test to the merge_reintegrate.py suite?
> > >
> >
> > I'm not sure we need a separate test for the --reintegrate case;
> > it seems reasonable to assume it does (and will) share the 'set +x
> > permission' logic with normal merges.
> >
>
> I thought about that, but this situation fixes itself after the 'svn
> merge/svn commit' combination. However, after using
--reintegrate. and
> committing, the executable bit is still not set, so I think there
might be
> something more going on there.
>
Ah, if there's a different in the results between merge and reintegrate
merge, then two tests are justifiable. (I missed that part of your
original comment.)
Thanks, Daniel. I've attached a new version of the patch, with amended
log message below.
Blair: I've also looked at *why* this problem exists, and it's due to
the "Special case" merge of binary files (libsvn_client/merge.c:1454).
If (right == working), then do a simple file copy from the temporary
file (which is not marked as +x). This means that we don't run
svn_wc_merge4. Unfortunately, this means that a workqueue is not
created, and the sync_file_flags is never run. As to what the fix is, I
have no idea.
Daniel^2:
I'm not working on this issue, I think it got assigned to me because the
ticket was originally assigned to the "svnmerge" component, for the
Python svnmerge.py script.
So I don't have an idea on the fix either :)
Regards,
Blair
