[RFC] tags in log output
zindar at gmail.com
Tue Apr 10 00:28:09 BST 2007
On 4/6/07, Alexander Belchenko <bialix at ukr.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Erik Bågfors пишет:
> > On 4/5/07, Alexander Belchenko <bialix at ukr.net> wrote:
> >> Yesterday I was thinking about this problem.
> >> Your patch is OK for me, but I prefer to explicitly
> >> pass list of tags for each revision as argument of LogFormatter.show()
> >> method. Instead of using rev_tag_dict. May be I'm wrong.
> > Well, I see three ways of doing it really
> > 1. pass list of tags for each revision as argument
> > 2. Do what I do now
> > 3. Pass branch into it, and let the formatter get to whatever it wants
> > in the branch, including tags
> > 1 might be better than 2, I can change that if you want.
> > 3 is probably most ugly, but it also allows new "things" in the
> > future, for example, if we build something like "notes/annotations"
> > for a specific revision, a log formatter could find that explicity and
> > add it to the log output.
> > I would really think it would be cool to be able to annotate
> > revisions, for example
> > bzr note -r 15 'WARNING: introduces bug XXXX'
> > bzr note -r 22 'Note: solves bug XXXX'.
> > I don't know exactly how useful this would be, but it would could be
> > something nice for bugtracker integration for example.
> > Anyway, 3 will allow this kind of extension without changing the call.
> > I'm open to changing it to whatever you prefer.
> I think from the testing point of view method 1 is preferable.
> Because no one else spoke, I'd like to suggest this variant.
I just can't figure out how to do this without breaking the API for
any log formatter plugins. Not that there are that many, but still.
> >> But I personally prefer to see tag info after revno, before commiter.
> > I actually think I agree. :)
> >> Also it's not difficult to make "tag:"/"tags:" field based on tags
> >> number.
> >> But it's really nitpick.
> > I don't like that, I think the output should be easily
> > grep:able/searchable/scriptable and a static "header" is easier to do
> > that with.
> OK. I understand.
> >> And, what allowed symbols for tag ids? Do bzr allows space in tag id?
> >> There is no explicit limitations on tag ids. So in the case when tag id
> >> contains space your output could be slightly unclear for multiple tags.
> > True..
> > Well, if space is allowed, one could do
> > tags: "tag with spaces" tag2
> > or perhaps
> > tags: "tag with spaces" "tag2"
> Yes, this will be good.
> If you rework your patch -- I'd like to give you +1.
> Probably it requires whitebox test as well...
> May be merge request will gain more reviews ;-)
I'll try that later, any ideas for not breaking the API?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 23741 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070410/d0a69b08/attachment-0001.obj
More information about the bazaar