attn mpool: Re: for discussion None vs null: vs current:

[Robert Collins]

Martin, we need your input on this now - you've expressed some thoughts
in the past..

On Tue, 2006-07-18 at 23:50 -0400, Aaron Bentley wrote:

> Robert Collins wrote:

> > I can see that the intent of our current
> > NULL_REVISION is not like NaN, and thus it works like the EMPTY_REVISION
> > I'm proposing. I think EMPTY_REVISION has a closer semantic fit to
> > people reading the code - folk reading the word NULL do not know /which/
> > NULL to interpret it as.
> 
> Perhaps ROOT_REVISION, or PROGENITOR?  EMPTY_REVISION's okay, too, but
> it doesn't hint at *why* we're using it.

I'm open to names here. I favour empty: because it accurately describes
the content (its an empty tree), whereas root/progenitor dont hint at
that. I think hinting at the content is more important than the uses -
because the content is invariant, but the uses may change over time.

> > As for delimiters, I dont see our very small selection of constants to
> > be a burden, it does not collide with our generated revisionids, and
> > revids from other systems can be prefixed: as long as there is not a VCS
> > called 'current', there should never be a conflict with 'current:'.
> > Using : is simple, clear and easy to read.
> 
> The idea was to have a simple rule for making detecting un-storable
> revisions.  But endswith(':') is probably a decent rule.

Ah. Frankly, I didn't think of that, because I assumed we'd have tests
for all of them :). But yes, I agree with endswith(':') -> non storable
as a simple policy.

> > Current proposal:
> > EMPTY_REVISION - 'empty:'
> > NULL_REVISION - 'null:'
> > CURRENT_TREE_REVISION - 'current:'
> > None aka NOT_A_REVISION - ':'
> 
> Still not thrilled with reusing 'null:' instead of using a new string,
> but I can deal.

I can see why, but as we haven't stored it anywhere, I dont think its a
problem :). We could start with 'newnull:' and then a release later
change to 'null:' if we wanted. As long as people use the python
constants that should be fine.

> > open discussion points:
> >  * should we use other delimiters than :.
> >  * does NOT_A_REVISION make sense?
> 
> The other place we use ':' is in revision specs.  So this would be a
> valid spec:
> 
> - -r revid:empty:..before:revid:current:

Looks nice to me. I'd probably want to use 
 -r revid:empty:..basis:

though, for clarity.

> I don't know whether that's worth worrying about.  Certainly, using '/'
> could be just as confusing.  Technically, a revision spec is never
> permitted where a revision-id may be used, and vice versa, so bzr itself
> shouldn't get confused.

Yup. I think we can make the parser work one way or another anyhow.

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/20060720/e789fb93/attachment.pgp