649503 - Figure out what needs to be done to hg webtools so that file moves/renames can be done without breaking log pages

Status: NEW

(Developer Services :: Mercurial: hg.mozilla.org, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

As an example, it is not possible to see the full log of nsIDOMWindowUtils at once.
If you first load
http://hg.mozilla.org/mozilla-central/log/1156b1885571/dom/interfaces/base/nsIDOMWindowUtils.idl
you get only the log after file move. To get older part of the log you
need to click the base link and the log link.

See also
http://mercurial.selenic.com/bts/issue2758
http://mercurial.selenic.com/bts/issue1576
And
http://selenic.com/pipermail/mercurial-devel/2011-April/029908.html

The log part is not as critical as the annotation, but still, I really
would like to have tools which work. Currently log is just quite useless
once the file has been moved/renamed.
If mercurial doesn't get fixed, could we patch hg.mozilla.org webtools?
And if yes, who could do the work?

Comment 1

[Justin Lebar (not reading bugmail)]

Would an acceptable solution here be to use a desktop GUI instead of webtools?  In my experience, webtools is pretty slow.

The hg folks have a list of GUIs; I have no idea if any of them is any good, but it sounds like it wouldn't be hard to be better than webtools...

http://mercurial.selenic.com/wiki/OtherTools

Comment 2

[Benjamin Smedberg]

Not to dismiss desktop tools entirely, but most of Mozilla code culture is built around the online tools, and we optimize all kinds of workflow around them, partly because linking to code and changes is easy. We should fix this to the extent possible. I know roc's been discussing this (again) on mercurial-devel, and we might be making some headway.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I brought it up on mercurial-devel in the thread linked in comment #0, and almost immediately hit a dead end. Matt Mackall just doesn't think things should work the way we think they should work.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Actually my part of the thread is here: http://selenic.com/pipermail/mercurial-devel/2011-April/029919.html

Comment 5

[Boris Zbarsky [:bzbarsky]]

Justin, as soon as MXR can integrate well with a desktop GUI I'll look at desktop GUIs.... ;)

Comment 6

[Johnny Stenback (:jst)]

I'm trying to pull together concrete steps for what we want here since we now have someone lined up to do this work (thanks Bob Moss for finding a resource!), but we need to know exactly what we want.

From reading comment 0 here it seems that there's a problem with annotation, but I understand that since from my testing here with both hg log dom/interfaces/base/nsIDOMWindowUtils.idl (command line) and http://hg.mozilla.org/mozilla-central/annotate/1156b1885571/dom/interfaces/base/nsIDOMWindowUtils.idl, it seems that annotate contains version information from before a move was done (and the web version even links back to the right old versions in the right place etc).

Assuming that's true, that leaves log. The command line versions of hg log has a -f argument that afaict does what we want already (except maybe make it clear when a move was made and from where to where the file(s) moved). But hgweb's log view most certainly needs attention. I think jwatt's comments in http://mercurial.selenic.com/bts/issue1576 explains quite clearly what we'd want here.

So it seems to me that if we do what jwatt suggests in his comment in issue1576 we'd be pretty happy here. And to clarify, that comment was:

Really hgweb should be listing history back to the time the file was moved,
have a very clear marker right across the page alerting readers to the fact
that it moved (and from where!), and then continue listing the file's
history prior to the move...repeat for all moves as necessary.

Let me know if we need more than that, or if we you think we want something different from that.

Comment 7

[Boris Zbarsky [:bzbarsky]]

The one remaining problem with annotation is that it's fail in the face of merges: it always follows the first parent of the merge as far as I can tell if both branches changed a line, which means it's fail for all of necko at the moment, sadly.

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

is that related to fime moves/renames? Or merges in general?

Comment 9

[Boris Zbarsky [:bzbarsky]]

Merges in general, but in necko's case there was a merge where one branch is an hg move and the other is an hg addremove.  So following the wrong branch means you lose all blame.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to comment #6)
> So it seems to me that if we do what jwatt suggests in his comment in
> issue1576 we'd be pretty happy here. And to clarify, that comment was:

That sounds good. Note that upstream already explicitly rejected this change, so it means we have to run a patched/forked hgweb (which is OK with me!).

Comment 11

[(not currently active) Ted Mielczarek]

I think we can essentially fork the hgweb log code into an extension, and have it override the built-in log command.

Comment 12

[Johnny Stenback (:jst)]

Ok, I think we have enough information here to get someone started on this. I'd prefer we deal with the annotate issue as a separate bug, for now I'm mostly interested in seeing the roadblocks for doing renames in the repository removed, and it seems like that's a much easier problem to solve as well.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Fwiw, the annotate issue arose because someone did a rename... and screwed it up.  I fully expect that to happen again once people start doing renames.