Comment 4 for bug 124859

Revision history for this message
Aaron Bentley (abentley) wrote : Re: [Bug 124859] incorrect repository detected with symlink to a branch

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

>> Following the symlink would mean that there would be no way to get the
>> version history of the symlink, and would have even worse effects with
>> "commit", "merge", "revert" et al.
>
> This is overgeneralising what I was reporting. At the moment the
> situation I created is already totally broken. I was not suggesting
> changing how we track versioning of symlink - I am talking about the
> behaviour of 'BzrDir.open(PATH)' exclusively.

Well, I am talking about what BzrDir.open_containing should do, and
that's implemented on top of BzrDir.open.

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"

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

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGkkUY0F+nu1YWqI0RAlJNAJ0blFg6SDZOl1GA3AZulBPSa1QnmwCfRP9R
xpETx/b0CRCyddtVo/ZIyII=
=EgKc
-----END PGP SIGNATURE-----