[rfc] bzr-colo into core

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/30/2011 11:15 AM, Alexander Belchenko wrote:
> John Arbash Meinel пишет:
>>>> I've deleted the branch a lightweight checkout points to, and you just
>>>> 'bzr switch --force' to another one. I don't know that we need to
>>>> implement force to begin with. But realize you can always have a
>>>> lightweight checkout pointing at a branch, and may not know it. (You
>>>> can
>>>> have a lightweight checkout of a branch on launchpad, for example.)
>>> Well, as I understand colocated support in bzr-core there won't be a
>>> lightweight checkout anymore, but new branch format with special
>>> reference to active branch. Is it true? If that's true then deleting
>>> active branch is not the same as deleting master branch of light
>>> checkout, is it?
>>
>> It really depends how we implement it. We *might* stick with the current
>> bzr-colo model just to maintain compatibility with older clients. We've
>> had a lot of push back in the past about format upgrades, so if we can
>> do things without it, we should try.
>>
>> In which case, we do just end up with a lightweight checkout pointing
>> somewhere in a directory of branches.
> 
> In this case we should fix absolute path problem.
> 

Martin has mentioned that this should be treated as a bug that can be
fixed every time you've brought it up. We just need to do so.

I know Aaron has mentioned that in his layout, he might move the working
tree, but he is unlikely to move the repository, so absolute paths
actually work better for him.  I do wonder what the breakpoint is.

IMO, it is pretty clear for colo. If the branch is a subdirectory of the
tree root, then use a relative path. If the branch is outside, then *I*
would say, if it is within 1 or 2 '..' then use relative path. Otherwise
use absolute path.

We've had weird effects with relative paths where you get:

 /path/to/my/branch
  ../../../../alternate/relative/path

If you follow that, you can see that it is actually still an absolute
path, we've just polluted it with a lot of parent pointers.

For my current model, everything is underneath a specific directory, and
I don't go above one '..' outside of that. So I might have:

branch-name
working-tree/ => ../branch-name

Or I might have:

subdir/branch-name
working-tree/ => ../subdir/branch-name

But I don't ever have:

branch-name
subdir/working-tree => ../../branch-name




>> Also note that the there are certainly arguments for being able to have
>> multiple checkouts of your "bundle-of-branches". In which case, you
>> still have the issue that someone might want to delete a branch which is
>> referenced by some lightweight checkout. And I don't know that we want
>> to refuse that. Though it could be nice to at least warn about it, to
>> help prevent people shooting themselves in the foot.
> 
> That's understandable and in any case it will work as of today (manual
> `switch --force` required). But for the working tree of colo-thing
> itself the question is open.
> 

So in the immediate term, I think it would be good to at least warn, and
possibly forbid deleting the active branch with 'rmbranch'. And if
people want it, --force could certainly be implemented.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2S/WYACgkQJdeBCYSNAAMgXQCgjQcgW2GUExCdkSt2iCaudrs3
93QAoL000jNjJbbL8C1gJV4OQF+y2yds
=Ex9O
-----END PGP SIGNATURE-----