[PATCH] [Bug 209281] Re: Windows diff apps don't understand symlinks created by Cygwin bzr diff --using

[Martin Pool]

On Wed, Apr 2, 2008 at 5:30 AM, Matt McClure <mlm at aya.yale.edu> wrote:
> Alexander suggested I move the conversation about bug 209281 from
>  Launchpad to this mailing list.  I've copied and pasted the most
>  recent comment from the bug report.  The patch itself is attached to
>  the report in Launchpad.

Thankyou for working with us to get a good patch for this.

>  In my case the symlink does harm: it prevents the diff program from
>  finding files in the symlinked path. And it fails to provide the
>  above value: even if TortoiseMerge could read the symlinked path, it
>  doesn't display the "full" relative path; it only displays the
>  filename portion.
>
>  I had the impression that symlinks were primarily used -- vs. copying
>  -- for better performance and reduced disk usage.

Maybe at least as a first step _try_symlink_root should just be
changed to return False and not make symlinks on the Windows or Cygwin
platform?

>  > Of course, it can handle Python implementations that don't provide
>  > symlinks. It only uses symlinks when Python supports them.
>
>  I considered keeping the nice pathnames by disabling symlinks
>  altogether for Cygwin, but I discovered that symlinks have another
>  advantage: the right side of the diff is the actual workspace file, so
>  I can edit it in the diff program if I want to change the diff.

So why not just pass the path to the working directory?

(I realize it's more general than that; you may be diffing two
historic revisions or two working trees.)

>  I wasn't able to find Python bindings for the Cygwin DLL. Do they exist?
>
>  Doing the transformation ourselves will produce quite a bit of code, I
>  think. We'd have to handle the Cygwin mount table. In general, C:
>  could be mounted anywhere.
>
>  I suppose parsing the "symlink file" is another option. Cygwin puts
>  the Windows path in there when it creates the symlink.

Actually this should not be necessary, as in this case we already know
what directory it should be pointing to.

-- 
Martin <http://launchpad.net/~mbp/>