Checkouts? Or just light bound branches?

[Jan Hudec]

On Fri, Jan 27, 2006 at 17:58:39 +1100, Robert Collins wrote:
> On Fri, 2006-01-27 at 07:29 +0100, Jan Hudec wrote:
> > On Fri, Jan 27, 2006 at 08:45:41 +1100, Robert Collins wrote:
> > > On Thu, 2006-01-26 at 22:30 +0100, Jan Hudec wrote:
> > > > On Fri, Jan 27, 2006 at 08:24:29 +1100, Robert Collins wrote:
> > > > > On Thu, 2006-01-26 at 15:15 -0500, Aaron Bentley wrote:
> > > > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > > > Hash: SHA1
> > > > > > 
> > > > > > It somewhat bothers me that checkouts and branches both have the concept
> > > > > > of last-revision.  Considering that revision-history is the only concept
> > > > > > that Branches represent, there's a lot of overlap.
> > > > > 
> > > > > Hmm. Well Branches represent the sequence, checkouts the point in time,
> > > > > IMO.
> > > > 
> > > > When revision-history goes away (as I assume is still the plan), they will be
> > > > the same.
> > > 
> > > Not at all: checkouts will still have files on disk that represent the
> > > instant the user is at, branches which are at arbitrary urls will not
> > > have files on disk - though they can generate the content for the
> > > -basis- tree.
> > > 
> > > If you wanted to say that Branch will be the basis tree and checkout the
> > > active tree, that might make sense.
> > 
> > Sounds like a confusion of terms.
> > 
> > What you call 'checkout' already exists, 'Working Tree', is, indeed,
> > differnt thing than a branch. However each working tree needs to know
> > what it's basis is. If it lives alongside a branch (as it always does so
> > far), it's basis is the current revision of that branch.
> > 
> > However as far as I understood, 'checkout' was supposed to mean a
> > working tree dislocated from the branch. But because that means there
> > can be several working trees for a single branch, each has to remember
> > which revision it was checked out from. So it's not *just* a WorkingTree
> > - it additionally has a current revision.
> > 
> > Now if current revision wholly defines a branch, well, than checkout has
> > a branch. Which means it is no longer dislocated -- and there is no need
> > for the term. It becomes just a bound branch with a working tree and
> > dislocated storage.
> 
> What you say has merit. I think another way of saying it is 'A bound
> branch with a working tree and misplaced storage *is* a checkout'.
> 
> If we allow such a beast to exist (I have no problem with that), and do
> not give working trees their own persistent 'last revision' marker (I'm
> still thinking about this), then having the specific term checkout is
> still useful, if only as a shorthand - 'I found a bug in
> bound-branches-with-working-trees-and-misplaced-storage' is unwieldy :)

Yes, as a shortcut (and because people are used to it from CVCS) the
term is useful.

But not having a special object for it (and not giving working tree it's
own last revision marker) should make the code quite a bit simpler.
Both displaced storage (for repositories) and bound branches are planed
anyway, so when they together give us checkouts, it's less work to do.
(It will make repositories behave slightly differently, because you
won't be required to actually keep any branches inside the repository).

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060127/b257b47d/attachment.pgp