[Python-Dev] devguide: Basic instructions on how to generate a patch with hg for non-committers.
Brendan Cully
brendan at kublai.com
Mon Feb 7 15:58:47 CET 2011
On Monday, 07 February 2011 at 15:46, Antoine Pitrou wrote:
> On Mon, 07 Feb 2011 14:34:35 +0000
> Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> > >>>
> > >> 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
Rdiff is meant to make diff work against remote repositories the way
it already does on local ones. So it *can* produce a diff between the
working directory and a remote revision, just as regular diff can do
for a local revision. But it can also produce diffs between any local
revision and any remote revision.
> remote, which is probably not what you based your work on. And if you
If you're talking about named branches, I think I agree (rdiff
predates a lot of the work done in hg to support named branches). I
assume you think the right target is the most recent remote revision
on the named branch you're working against? (rdiff does accept
symbolic names for remote revisions, including branch names)
> 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.).
rdiff is somewhat orthogonal to bookmarks/mq/etc. It's really just a
convenient wrapper for outgoing.
More information about the Python-Dev
mailing list