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

[Kai <kai willadsen gmail com>]

On 12 October 2010 07:22, Steve Franks <bahamasfranks gmail com> wrote:
> On Fri, Oct 1, 2010 at 6:23 PM, Kai <kai willadsen gmail com> wrote:
>> 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
>> _______________________________________________
>> meld-list mailing list
>> meld-list gnome org
>> http://mail.gnome.org/mailman/listinfo/meld-list
>
> Seems I may have spoken too soon.  Seemed to work fine on my ubuntu
> box, but it chokes on my FreeBSD system; this is probably a config
> issue as opposed to a bug, I'd guess.  On the freebsd system the patch
> either has no effect (still get all the asterisks in meld), or it
> causes meld not to see any changed files at all.
>
> Behavior is identical with a fresh download of either 1.3.3 or 1.4.  I

If you're only testing tarballs, then this won't make a difference.
The change was pushed after the 1.4 release, so for now it's in git
only.

> hacked the patch file so it wasn't trying to patch a/meld/vc/bzr.py
> and it applied cleanly, the I ran "sudo gmake prefix=/usr/local
> install" which also seemed to work.

There's an open bug about prefix installs not working, so it's
possible that this didn't do what it was supposed to.

> I also tried just ./bin/meld from
> the 1.3.3 or 1.4 untar'd folder, with the same results.  I seem to
> have gone astray somewhere...

As above, this won't work. Could you test git HEAD (you can run it in
the same way) and see if it has the same behaviour?

> Is there a way to get meld to dump a log of it's interaction with bzr?

Not currently. Adding logging is on my to-do list, but it's a long long list.

cheers,
Kai