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

Matt McClure mlm at aya.yale.edu
Tue Apr 1 20:30:52 BST 2008


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.

Matt

-- cut --

Thanks for all the feedback.

On Mon, Mar 31, 2008 at 10:19 AM, Aaron Bentley <email address hidden> wrote:
> That patch addresses the issue in the wrong place.

Could you suggest a more appropriate place?

> Bazaar creates a
> symlink in order to provide desirable pathnames. It would otherwise be
> using the real path already. By dereferencing the symlink, you're
> negating the purpose of creating the symlink in the first place.
>

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.

> 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.

On Mon, Mar 31, 2008 at 10:28 AM, Martin Pool <email address hidden> wrote:
> I am concerned that if we merge this as-is it will be a big
> performance regression because of forking a new process on every
> normalizepath call, something which would normally be pretty quick.

Regarding performance, "diff --using" doesn't seem like a case where a
few extra ticks can't be tolerated. I can't find any callers of
normalizepath other than the calls that my patch adds. Is that right?
 If so, the performance impact isn't felt anywhere other than diff
--using.

> It seems like we should be able to do this in-process, either by using
> a cygwin api callable from Python(?) or just doing the transformation
> ourselves?

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.

On Mon, Mar 31, 2008 at 11:12 AM, Alexander Belchenko <email address
hidden> wrote:
> Please, send your patch to Bazaar ML with [PATCH] or [MERGE] prefix in subject line,
> so more people will take a chance to look and review it.

Matt



More information about the bazaar mailing list