[PATCH] convert: svn-sink: test if execute bit was actually stored

[Matt Mackall]

On Wed, 2007-12-26 at 01:43 +0300, Maxim Dounin wrote:
> On Wed, 19 Dec 2007, Matt Mackall wrote:
> 
> > On Wed, Dec 19, 2007 at 06:13:43PM +0300, Maxim Dounin wrote:
> >> Hello!
> >>
> >> On Sat, 15 Dec 2007, Maxim Dounin wrote:
> >>
> >>> Hello!
> >>>
> >>> As of now, the command sequence in tests/test-convert-svn-sink leads
> >>> to conversion crash while converting revision where execute bit is set. As a
> >>> result - execute bit isn't stored in converted repo. Attached patch makes it
> >>> clear.
> >>>
> >>> As far as I debugged this, actual problem isn't in subversion sink code - but
> >>> instead in mercurial conversion source code. It reports extra copy operation
> >>> when setting execute bit follows copy for the particular file - because
> >>> execute bit is stored in manifest and file itself "thinks" it was copied in
> >>> last revision.
> >>>
> >>> It would be good if somebody with better knowledge of mercurial internals
> >>> (BOS?) take a look at this.
> >>
> >> I've spent some more time investigating this - and it looks like 'hg log
> >> -vC' also does wrong thing in this case depite the fact it has much more
> >> code to correctly detect copies.
> >>
> >> Testcase:
> >>
> >> hg init a
> >> cd a
> >> echo a > a
> >> hg ci -Ama
> >> hg cp a b
> >> hg ci -A -m 'copy a to b'
> >> chmod +x b
> >> hg ci -A -m 'set execute bit on b'
> >> hg log -vC --template '{rev} {file_copies%filecopy}\n'
> >>
> >> I can't figure out how to fix this correctly though. Not reporting copies
> >> when filelog wasn't changed by particular changelog revision doesn't look
> >> like a way to go - it will break test/test-log, notably issue391 test.
> >
> > The problem is that we're using a heuristic (whether the file is in
> > the list of changed files in a changeset) to decide whether to do a
> > copy check. But that will list files whose modes have changed as well
> > as just their contents.
> >
> > When we detect a case where a file may have been copied, we can do two
> > additional checks:
> >
> > - does the file revision's linkrev point back to the changeset in
> >  question? if yes, then the contents were definitely changed in this
> >  revision, and thus the copy happened in this revision.
> >
> > - if the above quick check fails, we can check the file revision in
> >  the parent changeset, and if it is different, we know the copy
> >  happened in the child. This test is potentially slow, but should be
> >  very infrequent.
> 
> Attached patch (against crew) implements the above algorithm in log 
> --copies and convert (mercurial as a source) and adds appropriate 
> tests.

It'd be better if this intelligence were moved into the filectx object.

-- 
Mathematics is the supreme nostalgia of our time.