Recording where branches that are absent are

[Aaron Bentley]

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

Robert Collins wrote:
>>I don't think that's an advantage.  If there's no branch at the
>>location, it seems odd for the operation to succeed.  It could lead to
>>an infinite loop.  (But it might make sense for open_containing.)
> 
> 
> Well, I am thinking of is a 'there is a branch you can access via the
> control dir here'. 

I understand that, but there is also need for 'there is a branch
physically here'.  (I will call that Branch.open_really below.)

> With the current design of recording this in the
> working tree we can have inconsistent states like:
> 
> .bzr/workingtree has a branch pointer to a remote location
> .bzr/branch has a branch

So, now that we've determined that repository, branch and working tree
are separable, you're now unconfortable with the notion of them being
entirely separate.

I don't see this as an inconsistent state, just a weird one.

> I think a huge advantage of this would be to make that impossible - not
> illegal, actually impossible.

I don't think your doing this has any such effect, unless you've got
different branch formats for these types.

>>| If the branch-location was in the checkout, then the only way you could
>>| find there was a distant branch would be to create a working tree
>>| instance and then look at its branch property.
...
>>Also, what you propose entails creating two Branch objects
...
> Not at all.
> BzrDirFormat7 [supporting split out repo/branch/checkout] when asked to
> open a branch will do
> branch_transport = self.transport.clone('branch')
> format = BranchFormat.find_format(branch_transport)
> # [compatability checks here if needed]
> format.open(branch_transport)
> 
> format is a factory - if the detected format on disk is a
> 'BranchReference', then the constructed and returned branch would be a
> real branch from the target url - there would be no instance of an
> unreal or pseudo branch constructed at all.

Similarly, you don't actually need a WorkingTree object in order to
produce a branch from .bzr/checkout/branch-location

> with respect to potential cycles, I would not expect this to forward,
> that is a reference could not be a reference to a reference.

In order to implement that, you will need Branch.open_really.  I would
prefer that Branch.open_really was named Branch.open.

>>I see 'location of the branch' as a property of the WorkingTree.  It
>>will be manipulated by working tree commands, and will affect the
>>behavior of the WorkingTree alone.  As a WorkingTree property, the way
>>it is represented should be subject to the checkout-format.
> 
> 
> I see it as a property of the .bzr control dir - we should only ever
> have one branch associated with a .bzr dir and this enforces that by
> recording *either* a branch *or* a reference, but not both.

I don't think it makes sense to have a .bzr/branch directory, if it does
not contain a branch.  I don't think you've shown that we should never
have both a branch and a branch reference.  Even if you do, it is quite
easy to enforce that rule without messing up the conceptual layout.

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

iD8DBQFD4Srj0F+nu1YWqI0RAmwpAJ9EC6yQe9g8st/eFQabnGUICo86bgCeP2BH
2wyv7sgU6GoPoBXmxZbIrsM=
=01v4
-----END PGP SIGNATURE-----