Re: 1.3.2 bzr 'fixes' - still can't deal with exec bit changes

[Kai <kai willadsen gmail com>]

On 29 August 2010 08:56, Kai <kai willadsen gmail com> wrote:
> On 13 July 2010 19:07, Kai <kai willadsen gmail com> wrote:
>> On 13 July 2010 10:21, Andrew Beyer <beyer andrew gmail com> wrote:
>>> On Mon, Jul 12, 2010 at 4:42 PM, Andrew Beyer <beyer andrew gmail com> wrote:
>>>> In any case, couldn't meld use the "--short" form of the stat command?
>>>> Which I believe puts all the flags before each filename, and is
>>>> probably easier to parse anyway.
>>>>
>>>
>>> a quick glance at _lookup_tree_cache() in vc/bzr.py makes it look like
>>> the parsing is broken for other things too. Symlinks,  file renames,
>>> and kind changes (dir to file, or vice versa) can all add extra
>>> annotation after the filename in stat command output which isn't dealt
>>> with at all. The short form at least puts flags before the filename,
>>> which would disambiguate the "*" issue, but still shows renames as
>>> "old-filename => new-filename" and similar for kind changes. It looks
>>> like even in the short form, an "@" is appended on symlinks, which is
>>> also a valid if uncommon character in a filename.
>>
>> Sounds like using --short would be a thoroughly sensible option.
>> Obviously the parsing could use some improvement as well, but if we
>> can easily move to --short and fix several bugs, then that sounds
>> great. Can someone file a bug?
>
> Lacking a bug, I thought I'd have a go at this anyway. I've attached a
> patch that switches bzr to using the short version of the status,
> which certainly seems more parseable. Unfortunately, bzr doesn't seem
> to have any documentation on what most of the status flags actually
> mean, so I've just ported the subset that I think are interesting for
> (and supported by) Meld.
>
> I'm not a bzr user, and only have a limited array of test cases at my
> disposal, so testing and feedback would be great.
>
> Looking at this has also made it obvious that we should at least
> figure out how to deal with moved files, being the one common,
> obviously interesting case that we don't support properly for any VC.

Does anyone have feedback on this? It's obviously bugging some people,
but I'm not going to push the fix unless it's actually working for
people who use bzr, and that's not me.

cheers,
Kai