revids that include periods are interpreted as ranges

[John Arbash Meinel]

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

On 8/10/2011 7:19 PM, Robin Luckey wrote:
> 
> I have found several Bzr repositories with revids that include the
> substring '..' within them. Although these are single revids, bzr
> interprets them as revid *ranges*, and thus they cannot be passed as
> parameters to the bzr command line tools.
> 
> For example, lp:nvda contains such a revid in its first revision:
> 
> http://bazaar.launchpad.net/~nvda-core-dev/nvda/main/revision/1
> 
> The revid for this revision is:
> 
> svn-v3-list-QlpoOTFBWSZTWbrL2vUAAB1VgAAQABCAQDrrnqAgAFCgaaGRkxBoTIJ6mmaNRwhndFAoNhZjh_YY4a01fOg1ulgNNC2UrzPdXXEnDpX8XckU4UJC6y9r1A..:dbe06fc7-9119-0410-a01d-9dbf589ecbba:trunk:46
>
>  The '..' substring causes bzr to believe this is a range spec, and
> thus any command line operations that attempt to use this revid as a
> parameter will fail:
> 
> $ bzr log --show-id -v --limit 1 -c
> 'svn-v3-list-QlpoOTFBWSZTWbrL2vUAAB1VgAAQABCAQDrrnqAgAFCgaaGRkxBoTIJ6mmaNRwhndFAoNhZjh_YY4a01fOg1ulgNNC2UrzPdXXEnDpX8XckU4UJC6y9r1A..:dbe06fc7-9119-0410-a01d-9dbf589ecbba:trunk:46'
>
> 
bzr: ERROR: Option --change does not accept revision ranges
> 
> There are dozens of such revids in this repository, and I have found
> several other repositories affected by this problem. All of the
> offending revids appear to have been generated during conversion from
> Subversion.
> 
> Is there any workaround for this problem? Is there any way to escape
> these revids or to coerce bzr so that they will not be interpreted as
> ranges?
> 
> Cheers, Robin Luckey
> 

You could try using "revid:" syntax, but I'm pretty sure the code that
does "-r" and "-c" parsing splits on '..' before it gets to the
RevisionSpec objects themselves.

Certainly there is a limitation here. As without using ".." as a special
meaning, how would one enter a range between two revision-ids.

This is the first I've seen it come up as an issue, so we haven't
incorporated an escape mechanism, etc.

I know Robert has mentioned long ago, that we would *like* a recursive
descent parser. (Which I think means, try the whole string as an
identifier, grab as much of it as fits a spec, then split of the rest
and start parsing the remainder, etc.)

As Alexander mentioned, one workaround is to address these revisions by
their revision number, instead of by their revision id.

bzr itself is unlikely to generate '..' in revision-ids, just because of
how the revision-ids are generated. But there isn't an explicit trap for
them. (Specifically, I just tested: BZR_EMAIL="Test <test..user at email>"
and the .. ends up in the revision-id.)

So certainly, file a bug on this, though I don't have any
quick-and-cheap answers for how to fix it. I know at one point we
discussed using multiple '-r' flags to define a range, rather than '..'
syntax. Though that would be a pretty large change at this point.

Maybe we could change the parser so that if you do "revid:" it won't
accept '..' unless it was followed by an obvious revspec. For example:

 bzr log -r "revid:abcd..xyz"
Would be treated as "abcd..xyz" but
 bzr log -r "revid:abcd..revid:xyz"
would be treated as a range between 2 revisions "abcd" and "xyz".

I would probably want it to support "revid:" and simple numbers (for
revnos). Mostly because I like to do things like:
 bzr log -r "revid:abcd..-1"

But honestly, I don't use raw revids particularly often. But they
certainly are meant to be available, and uniquely identify a revision.
Especially for automated processing, etc. So I would like to have a way
to work with your use case.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5KQJ0ACgkQJdeBCYSNAANfVwCfTG+qTPUU7OfpjvYmv20xNE2L
x2QAn3E0hvbFBDqLU/X8okvXfSjVgJ0w
=/rRL
-----END PGP SIGNATURE-----