Checkouts? Or just light bound branches?

[Robert Collins]

On Mon, 2006-01-30 at 16:56 -0500, Aaron Bentley wrote:
> -----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.

mmm, i dont think its at all clear that its that simple. Consider a web
site where you have ftp access to upload (thats common). With a cron job
that the sysadmins could setup, commits will be lightweight and cheap.
But without it you need to upload the [potentially megabytes] of content
in toto every time. 

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

FSVO very well. Stale files and scalability concern me greatly here.

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

Thats not true. I have SFTP running on my desktop but not my laptop, and
no network file system most of the time. Its *much* more convenient for
me to push to my desktop, and to hack locally there, rather than to pull
instead of push, or to guarantee cheap network access to it.

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

Skipping the rest until we get consensus on the top part.


> > a) seems *far* more complex to me.
> 
> Don't you mean b)?

Except to clarify that yes, I meant 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?

In design terms its there predicated on the discussion above that we
dont have consensus on yet - so within this email only.


Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060131/c02e0de5/attachment.pgp