On Mon, 07 Feb 2011 14:34:35 +0000
Michael Foord
And from the description it sounds like rdiff will be very useful for our usecase. I'm not sure it is really. When you commit multiple changesets locally you really want to use something like named branches or mq to track them. Advocating rdiff is advocating something SVN-like, it's not very helpful IMO.
Although often you want to merge in a single commit and erase the commit history of the branch you worked in (as discussed previously).
Yes, but apparently rdiff compares the *working copy* rather than the local repository. Also, AFAIU rdiff will compare against the tip of the remote, which is probably not what you based your work on. And if you have to specify revisions by hand, it kind of defeats the point (you want hg to track changes by itself, which is why you want to use one of named branches / bookmarks / mq / etc.).
So are you advocating rebasing before merge as the alternative?
I'm not advocating anything in particular really. I think creating a named branch "foo" (or a bookmark? I've never used them but it sounds like they might do the trick) and then using "hg di -r py3k" to get the diff against upstream is very reasonable. That's without any hg extension activated. Throwaway clones are good too, since they avoid the issues with "rebasing" or "erasing commit history". But if we suggest people use some extension, I'd rather see us advocate mq (or shelve or any equivalent) rather than something low-level such as rdiff. Regards Antoine.