Help with extension writing

[Dirkjan Ochtman]

On Wed, Apr 14, 2010 at 10:08, Matthew Watson <mattw.watson at gmail.com> wrote:
> I'm a senior dev at Atlassian and we are looking at how we could add
> mercurial support to FishEye
> (http://www.atlassian.com/software/fisheye/) and Crucible.

That's great to hear! I see a lot of complaining in my twitter search...

> We're also trying to make this is low maintenance as possible, so
> trying to stay away from internals that might change over time as much
> as possible (we have no control over what version of mercurial our
> clients will use, but can recommend  versions that our extension will
> work with) - I see that there is a commitment to change the command
> line as little as possible, so figured the comands.py functions would
> be good.

I think it might be easier to use ctxs; we're pretty committed to
keeping that API stable, as well, and it looks like it map better to
your usage.

> So for every commit we see, we want details about that commit (basic
> stuff from changectx), details about the files that have been modified
> in that commit (this may be counter to mercurials backend model),
> files added, deleted, copied, moved, modified (which we get ATM by
> looking at the diff --git output), their size (in the filectx), their
> content (hg cat) and their ancestral parent(s).

If you're going to read contexts, be sure to read in rev order,
because that should be much faster for unpacking manifests (which you
need to do to get enough information about file-level changes).

> But it looks like this will not find merged in parents of a file, as
> log looks for the presence of the file in the changectx.files() for
> the given branch and a file, if merged from another branch, will not
> be listed in there (correct?). Instead I'd need to navigate the merge
> branches as well. Is there a better way to do this?
>
> Or, can I look through the file log to find this out in a different way
> * find previous revisions of the file and see which changectx they appear in?
> * Look for the file in the manifest and look back through parent
> changectx's to see when the nodeid of the file in the manifest
> changes?

Going through filelogs and following linkrevs back might be easiest
here. (Although you should definitely check per-file nodeid in both
parents first, I guess.)

> I guess for me, the data I'm getting is correct for straight single
> parent commits, but merge commits seem to amalgamate the data from the
> 2 parents in ways I don't yet understand - I was assuming there was a
> "primary" parent (ctx.parents()[0]) and that all the merged in changes
> would appear in a changeset for that changectx, which is what diff
> --git shows you when you diff ctx to ctx.parents()[0], but is not what
> is represented necessarily in the ctx.files() for that changectx? I've
> gone through a lot of the wiki, the docs, the Definitive Guide etc,
> but it's hard to get a clear picture.

ctx.files() in merge commits represents just the files that are
different from either parent; things that explicitly had to be merged.
IOW, if the file in the merge is the same as that file in either
parent, it will not be in the merge's ctx.files().

> We are also trying to get clear if tying a file revision to the
> changectx it occurred in is a bad idea and instead we should be using
> the actual file revision as shown by "hg manifest --debug" or
> node.hex(ctx.manifest()[file])

Hmm, it depends on what you're using it for, I guess. My initial guess
would be that yes, the filelog-level nodeid makes more sense.

> Sorry if this is not clear (and there are a lot of different questions
> in here!), my understanding of the mercurial data is evolving daily
> and I'm trying to fit it to a different model that we already have (or
> decide if that is not possible!)

Good luck, and be sure to ask here for anything else you need (or try
#mercurial on freenode for faster feedback).

Cheers,

Dirkjan