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

[Kai <kai willadsen gmail com>]

On 27 September 2010 17:30, Kai <kai willadsen gmail com> wrote:
> 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.

This patch has now been pushed.

cheers,
Kai