[RFC] CURRENT_TREE_REVISION ?

[Robert Collins]

On Fri, 2006-06-16 at 09:00 -0400, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Robert Collins wrote:
> > I'm thinking of adding a new special revision marker, like null: is
> > today, which will be current:.
> > 
> > add_revision and get_revision will guard against this being
> > stored/retrieved.
> > 
> > It will be the revision id for the working tree.
> 
> I've thought about doing the same thing for quite a while.  It feels
> somewhat icky to have a revision-id for something that's not a revision
> (yet), but it solves a bunch of problems, so I'm +1 overall.

Ok, I'll write up a patch to introduce this.

> I'm not sure current: is the clearest thing-- I immediately thought it
> meant WorkingTree.last_revision().  Maybe 'directory:'?

'workingrevision:' along the lines of 'working tree' ? perhaps
'working:' to indicate its a revision in progress not a complete one.

> > This allows the following things without [much?|any?] special casing:
> > 
> > * bzr log can show the pending merges as being merged into the current
> > tree.
> 
> (some formatting issues, though.  Log output is designed so the merging
> revision comes first.)

Ack.

> > Possibly there are other applications for it.
> 
> Bzr revert and shelve can use it to create bundles for the working tree
> instead of backup files or patches.

As long as we have the appropriate guards to ensure that these bundles
can /never/ land in a repository, I'm happy with it being used for that.

> "bzr merge -r -1..revid:current: foo" can be used can be used to copy
> uncommitted changes from foo.  (See also bzrtools shove, though.)

also of use: 'bzr merge -r revid:current:'. Actually, I'd like to
suggest that RevisionSpec barf on the literal value of the ID - I think
this should be an internal symbol only. We can add a 'current:' or
'tree:' or other namespace qualifier directly to RevisionSpec without
needing it to go through the revid: layer.

> > I'm thinking of an api like 'tree.get_revision()' to get the revision
> > object that owns a tree. For EmptyTree this is a Revision object
> > representing 'null:', for WorkingTree this is a Revision object
> > representing 'current:' with parents matching the parents list of the
> > tree - i.e. null: for a newly inited tree.
> 
> RevisionTrees already have a revision_id member, so we chould just
> provide that to the others.

Well, I was meaning this api to return the objects, not the id. This
would mean for instance that WorkingTree.revision_id would remain
undefined - because 'current:' is not usable in Repository apis, so
having it is not useful - but you can get the Revision object.

> One downside to this idea is that the 'current:' revision id doesn't
> have a fixed meaning, and two trees with that revision id may not refer
> to the same thing.

This is why I'm stressing that it should be verboten to store it or put
it in a repository .

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: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060616/5f21b3a5/attachment.pgp