Get the unified diff from a bundle against an http repository
Christophe Attias
christophe.attias at amadeus.com
Mon Aug 30 07:25:42 UTC 2010
Thanks a lot Greg, that's what I thought.
So I came up with a workaround, I generate the diff at the same time as I
generate the bundle.
For the documentation, I'll try to do like you said.
Thanks again.
Best regards
Christophe Attias
Greg Ward <greg-hg at gerg.ca>
To
Christophe Attias <christophe.attias at amadeus.com>
cc
mercurial at selenic.com
Subject
Re: Get the unified diff from a bundle against an http repository
Greg Ward <greg-hg at gerg.ca>
Sent by: gerg.ward at gmail.com
28/08/2010 21:54
On Fri, Aug 27, 2010 at 12:46 PM, Christophe Attias
<christophe.attias at amadeus.com> wrote:
> Here is my problem.
> I have a local dev clone of my 'central' repository (which is an http
repo).
> On my local clone I perform changes.
> Then I create a mercurial bundle containing all the changesets that are
in
> my local clone and are not present in the central one.
> So far so good.
Good, sounds sensible so far.
> The goal for me is to be able afterwards to generate a unified diff
> corresponding to the content of my bundle (for instance to perform a
code
> review on it) but without having access to my initial local dev clone.
I don't think it's possible. As I understand it, a bundle just
contains binary deltas, so there is no way to reconstruct the context
without access to the original text. And you can't have a unified
diff without context.
> I agree that I need to be "inside" a repository that at least contains
the
> base changeset of my bundle to be able to generate the diff, which is
the
> case of my central one.
> And it works like a charm when my central repository is a local one, but
it
> can't make it work with an http repo.
Right, because with an HTTP repo, the data is "out there" on the
network. Mercurial would need a wire protocol for fetching whole
revisions, and that doesn't exist. That's what local repos are for.
> By the way, I'm writing a lots of mercurial extensions for my company
and I
> find it great BUT (yes there is always a but) it is really hard to find
good
> informations about the Mercurial Api.
> I always have too look into the code of Mercurial to understand how I
can do
> and then I'm clearly not sure I'm doing it the good way ...
> Am I missing something ?
That was my experience too. My solution: whenever something is not
clear from reading the docstrings and I have to read the code, I write
a docstring explaining what I learned from the code. Then I submit it
as a patch -- see http://mercurial.selenic.com/wiki/SuccessfulPatch
and http://mercurial.selenic.com/wiki/ContributingChanges. If I got
something wrong, someone will probably point out my mistake, and I'll
revise and resend the patch. When I get it right, then hopefully the
patch will be accepted and Mercurial gets a little bit better.
And of course feel free to improve the wiki. The MercurialApi page is
enough to get you started, but it could probably be more detailed.
Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20100830/72dbbe61/attachment.html>
More information about the Mercurial
mailing list