On 12 October 2010 07:22, Steve Franks <[email protected]> wrote: > On Fri, Oct 1, 2010 at 6:23 PM, Kai <[email protected]> wrote: >> On 27 September 2010 17:30, Kai <[email protected]> wrote: >>> On 29 August 2010 08:56, Kai <[email protected]> wrote: >>>> On 13 July 2010 19:07, Kai <[email protected]> wrote: >>>>> On 13 July 2010 10:21, Andrew Beyer <[email protected]> wrote: >>>>>> On Mon, Jul 12, 2010 at 4:42 PM, Andrew Beyer <[email protected]> >>>>>> 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 >> [email protected] >> 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 _______________________________________________ meld-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/meld-list
