[PATCH 8 of 8] changelog: exclude abandoned changesets from heads

Pierre-Yves David pierre-yves.david at logilab.fr
Mon Jun 6 08:16:56 CDT 2011


On Mon, Jun 06, 2011 at 03:10:55PM +0200, Martin Geisler wrote:
> Pierre-Yves David <pierre-yves.david at logilab.fr> writes:
> 
> I actually don't like the idea of keeping a common changelog._hidden set
> very much since different part of the code will have to make sure to
> update it correctly. For abandoned, it feels easier to recompute the
> abandoned changesets the first time you ask if a changeset is abandoned.
> 
> Perhaps we could instead let changelog.hidden be a method that would
> call registered handlers in turn to see if any of them wants to hide a
> given changeset?

I agree we need a mecanism easy to extend.

> > hidden methods will return "None" if the changeset is not hidden,
> > otherwise it returns a three tuple (<time>, <author>, <reason>).
> >
> > <time> will be the date when the operation that make this changeset
> > hidden occurred, <author> will be the responsible user and <reason> a
> > string describing why this changeset his hidden.
> >
> > In the abandon case the value will be:
> >
> >     <time> = commit time of the abandoning changeset
> >     <author> = author of the abandoning changeset
> >     <reason> = "Abandoned by <abandoning changeset id>"
> >
> > Having a richer interface will help us to print useful data about
> > changeset hidden by various sources. Hiding changeset is tightly liked
> > to editing history. Editing history is a tricky topic, offering as
> > much data as possible to the user is important.
> >
> > Implementation wise, the hidden set will be a dictionary. Allowing
> > None value for <time>, <author> or <reason> is to be discussed.
> 
> The changelog._hidden set is not persistent, so I think it is better to
> store this information somewhere else. For abandoned changesets, the
> data is stored in the changesets and the _hidden set is then filled in
> on startup -- other mechanisms will want to store their own cache file
> and then fill in _hidden based on that.

Yes, this information is not means to be persistent. Every hidding mechanism
will be responsible to store and compute this data. But I propose that we
require a common set of information to be provided when something decide that a
changeset must be hidden. It's not a common storage for the information. It's a
common way to provide information to the UI.

-- 
Pierre-Yves David

http://www.logilab.fr/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110606/d77e6daa/attachment.pgp>


More information about the Mercurial-devel mailing list