Checkouts? Or just light bound branches?

[Aaron Bentley]

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

Robert Collins wrote:
> Saying that 'a'
> should not have a working tree is in this case inappropriate - we'd be
> telling the user how to work, and I can certainly think of multiple use
> cases for this exact layout [for example, a website under vcs, or using
> my laptop and desktop interchangably].

Either you can log in, and therefore you can have local changes, or you
can't log in, and so you most likely don't.  If you can log in, you can
push instead of pull.  If you can't log in, we can do a destructive tree
update instead of a merge.

A web site under VCS would work very well if push just overwrote the
working directory with no attempt to preserve local changes.

A desktop and laptop are highly likely to use a network filesystem to
synchronize, in which case, they will do working-tree merges.  In any
case, if you have the possibility of having local changes, you have the
possibility of doing 'pull' instead of 'push'.

> So before we talk model, we need to see what is required to solve this.
> And I think its clear that to solve it we need a last-revision property
> of the working tree that is left at its previous value during that sftp
> operation that the 'commit' performs.

If I agreed about the first part, I would agree with this.

> Now, in terms of model, if we do this via reusing bound branches, then
> the branch 'a' above will actually need to be two branches - a local
> lightly bound branch representing the working tree content, and a normal
> branch with storage representing the logical branch, and both of these
> in the same place.

I never intended this to be used with out-of-date working trees.  My
feeling is that out-of-date working trees are a bogosity.  Otherwise I
wouldn't have proposed lightweight bound branches.

> So now Occams razor comes in: we have two proposals:
>  a) Serialize the [currently implicit] last revision that represents the
> text the working tree was last updated to by bzr.
>  b) Use a bound branch everywhere that a working tree is present to
> record the same implicit last revision.
> 
> a) seems *far* more complex to me.

Don't you mean b)?

Certainly, if I agreed that it should be possible for working trees to
get out of date, I'd agree that we needed to serialize the last revision.

> Note that in *neither* case do we have to add a last-revision property
> to any objects: we have it in both Branch and WorkingTree already.

Is this new?  When did it happen?  Is it writable?

> Given the above, the question becomes - which is simpler/better:
>  a) add a new class
>  b) add a flag to bound branches to say 'storage is at the
> bound-too-branch' AND I must have a working tree.
>  c) add a marker to working tree recording where the branch is rather
> than have it always at '.'. (And this could be recorded in the branch
> control dir now that I think of it - as a reference object [see my other
> mail for details])

I hope I read that wrong.  You don't mean .bzr/branch/branch-location,
do you?  A major goal of separating out the directories was so that each
 object's control files were independent of other objects' control files.

> For update however, there are significant differences: when a bound
> branch has diverged, rather than being a prefix, we need to turn the
> divergent commits into a pending-merge.

This is behaviour that we haven't discussed and certainly haven't
finalized.  I would have assumed the merge command was required when a
bound branch was diverged.

> What concerns me a little is the layering - bound branches seem to be
> somewhat dependent on the working tree to deliver the UI we want - but I
> haven't looked deeply at Johns branch yet, so maybe hes addressed that
> there.

I don't understand what you mean by this.

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

iD8DBQFD3ouM0F+nu1YWqI0RAngOAJ4yIIp9Zv0wjfEw6LyCnjpBTu8NtQCfZ7sR
aUqfneIy/x8wks4u/qvzQig=
=XGt4
-----END PGP SIGNATURE-----