Comment 6 for bug 124859

Revision history for this message
Robert Collins (lifeless) wrote : Re: [Bug 124859] incorrect repository detected with symlink to a branch

On Mon, 2007-07-09 at 14:24 +0000, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Robert Collins wrote:
> >> The symlink may well be a versioned file, so the containing directory is
> >> the correct place to search. This allows "bzr log link" to give the
> >> version history of the symlink, while bzr log "subproject/subtree" will
> >> give the version history of the subtree.
> >
> > I think getting the log for the history of 'link' in the tree link is in
> > should be possible. Right now its not possible at all.
>
> It is possible, but not using the symlink.

??? Its certainly not possible from the command line in the example I
have.

> Given:
> tree_a/link
> tree_b/file
>
> where tree_a and tree_b are both Bazaar working trees, and link is a
> pointer to file, what should "bzr commit tree_a/link" do?
>
> If BzrDir.open follows symlinks, then this will commit tree_b/file. I
> believe this is incorrect behavior, because tree_a/link may legitimately
> refer to the symlink, not the file, and this is the only way of
> committing the symlink. Yet by definition, a symlink's target always
> has its own name. So if you want to commit "tree_b/file", you can do
> "bzr commit tree_b/file"

I don't think your example is correct. If bzrdir.open follows symlinks,
and tree_a/link points to tree_b/file, then BzrDir.open('tree_a/link')
will fail (tree_b/file is not a bzr tree);
BzrDir.open_containing('tree_a/link') will return (BzrDir('tree_a'),
'link').

If tree_a/link points at tree_b, then and only then does the confusion I
am talking about occur.

> >> In sum, symlinks are first-class entities in Bazaar, so it does not make
> >> sense to follow them.
> >
> > They are first class entities, but that does not preclude following them
> > at appropriate times.
>
> Okay, let me say that "when the symlink is the terminal path element" is
> not an appropriate time. You're right that this has come up before, and
> this is the reason we didn't "fix" it then.

Thats true. However, this current behaviour is a regression AFAICT - I
believe that BzrDir.open() used to follow symlinks (but
BzrDir.open_containing never did, and should not start following them).

Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.