[PATCH 1 of 1] mq: add functions to attach information items to patches

Matt Mackall mpm at selenic.com
Thu Aug 11 16:00:13 CDT 2011


On Thu, 2011-08-11 at 22:52 +0200, Ingo Proetel wrote:
> Am 11.08.2011 21:29, schrieb Matt Mackall:
> > On Thu, 2011-08-11 at 18:56 +0200, Ingo Proetel wrote:
> >> # HG changeset patch
> >> # User Ingo Proetel <proetel at aicas.de>
> >> # Date 1313081661 -7200
> >> # Node ID 7f36cb5749a614fc32defa25ba96842f4c7d195e
> >> # Parent  3ab40477ce60e1757ceeaa49e2c9d2790fbb47e0
> >> mq: add functions to attach information items to patches
> >>
> >> Allow programmers to attach some information such as bug ids or review ids to a patch.
> > 
> > Why do we want this in core?
> >
> 
> If we can agree that it make sense to store this kind of information in
> the series file I think it makes sense to provide an API in mq manage
> this data.
> 
> >> +    def attachinfo(self, idx, name, values):
> >> +        '''Attach some information items with a patch. The items get stored in
> >> +        the series file as comments in the form '#name:item0 #name:item1 ...'.
> >> +        If values is None the named items are cleared.
> > 
> > This doesn't seem like the best place to store this data, given that the
> > series file is intended to be user-editable.
> > 
> 
> Actually it is possible to add review requests to the server manually
> then it helps that series is user editable.
> I guess the whole patch is more of a convenience for extension developers.

The downside of adding convenience functions for third-party code is
that if it has no first-party uses, it raises our maintenance burden.
It's also liable to bit-rot or be garbage-collected. So a feature
generally has to has some first-party utility to meet the acceptance
threshold.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list