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 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. 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... Is there a way to get meld to dump a log of it's interaction with bzr? I attached the patched bzr.py just in case there's a clue in there... Thanks, Steve
Attachment:
bzr.py
Description: Binary data