[RFI] bzr-keywords & forward compatibility

Parth Malwankar parth.malwankar at gmail.com
Thu Apr 2 06:39:56 BST 2009


On Thu, 02 Apr 2009 10:19:43 +0530, Ian Clatworthy  
<ian.clatworthy at internode.on.net> wrote:

> After eol conversion, keyword templates are likely to be
> the most widely used application of content filters. I've
> put together the bzr-keywords plugin for this purpose and
> I'd like feedback from the list on the design. As the many
> days of eol discussion have shown, "community intelligence"
> vastly exceeds mine alone. :-)
>
> So my #1 issue is getting a *stable* set of keywords with
> stable expected content. Users need to be able to rely on
> names being supported & semantics going forward. It would
> be nice to have bzr-keywords bundled with the Windows &
> Mac installers in either 1.14 or 1.15 but we don't want
> widespread usage until we're comfortable of retaining
> compatibility going forward.
>
> So what are the bits that are potentially "unstable"?
>
> 1. The exact content of User & Author. Right now these are
>    the full name + email address. Separate keywords are
>    provided (User-Email, Author-Email) to get at just the
>    email bit, making them easier to embed in URLs or Web
>    pages for example. I wonder whether User & Author ought
>    to *just* be the username bit - it easy to put them back
>    together but hard to pull bits out? If they are just the
>    Username, then perhaps we ought to name them User-Name
>    and Author-Name respectively? We could support all of
>
>    User (all of it)
>    User-Name (just the name)
>    User-Email (just the email)
>
>    But I wonder whether the first is really needed if we
>    provide the latter 2.
>
> 2. Multiple author handling. Right now, Author is the first
>    author in the list and there's no way to get at the others.
>    One simplistic answer is more keywords like:
>
>    Author2
>    Author2-Email
>    Author3
>    Author3-Email
>    Author-Count
>
>    If we did that, then should we rename Author to Author1?
>    Also, maybe we ought to make them *look* like list items so
>    that they could become exactly that iff we add a real list
>    interpretation capability later, i.e. Author[1],
>    Author[2]-Email, etc.
>
> 3. What's missing? These can be added later and shouldn't break
>    existing keywords, but perhaps looking at additional needs will
>    help us tune the names of current keywords? Some things we
>    might want to add include:
>
>    Nick (or Branch-Nick to be more descriptive?)
>    Committer
>    Committer-Email
>    revision properties like the svn rev-id.
>
> I'll attached the current help for those interested in this
> feature and helping refine it.
>
> Ian C.

I am not sure if this requirement specifically belongs to
keyword filters but one common need I have come
across is to add the VCS unique checkin id to some file
that can use this as a part of version number string
in the finished product.
E.g. product 1.1 (rev:nnnn).
This file could be a version.[h|py|..]

Normally, keywords cannot be used for this purpose
as they get expanded only for the current changeset
and version.xxx is not a file anyone touches.

Is common to come up with build hooks to deal with
this. E.g.
http://www.innovationontherun.com/creating-a-build-number-with-ant-and-subversion/

The issue with build hooks is that if a user takes
a simple tarball to do the build, the build won't have
a valid revision number.

I expect this file (version.xxx) would become a part
of every changeset after being automatically updated.

I was wondering if would be possible to do something
like this with filtered views. If this is outside of
the filtered views requirements, please feel free to
ignore this.

Parth




More information about the bazaar mailing list