Le 06/02/2011 17:15, Antoine Pitrou a écrit :

On Sun, 06 Feb 2011 02:10:15 +0100 brett.cannon wrote:

...

To create your patch, you should generate a unified diff from your checkout's top-level directory::

- svn diff > patch.diff + hg outgoing --path > patch.diff

Should be --patch. The problem is that it will show one several patch per changeset, which is normally not what you want (it's a pity "hg out" doesn't have an option to collapse them all).

I suggest you request that feature upstream. In the meantime, one can use hg diff -r $upstream-tip:tip to diff two anonymous branches. Using a named branch or local tags helps identifying $upstream-tip. Regards

On Sun, Feb 6, 2011 at 08:15, Antoine Pitrou wrote:

On Sun, 06 Feb 2011 02:10:15 +0100 brett.cannon wrote:

...

 To create your patch, you should generate a unified diff from your checkout's  top-level directory::

-    svn diff > patch.diff +    hg outgoing --path > patch.diff

Should be --patch. The problem is that it will show one several patch per changeset, which is normally not what you want (it's a pity "hg out" doesn't have an option to collapse them all).

Yeah, that is a perk of mq.

...

 If your work needs some new files to be added to the source tree, remember -to ``svn add`` them before generating the patch:: +to ``hg add`` them before generating the patch::

-   svn add Lib/newfile.py -   svn diff > patch.diff +   hg add Lib/newfile.py +   hg outgoing --patch > patch.diff

You should commit before using "outgoing", otherwise the added file is not in the repo (and therefore not in the patch).

The problem with hg (and other DVCSes) is that allows for *several* local workflows, and therefore it's harder to advocate one of them in such tutorial docs. I wonder what Georg and Dirkjan suggest.

Well, I wouldn't say harder. We just choose one we like the most and advocate that while stating upfront this is just one of many different ways someone can choose to work.

We could perhaps present SVN-like "work in the working copy" workflow (without local commits), and let seasoned hg users choose other workflows they like more (they don't need our help anyway).

I would rather give people some simple workflow that has some benefit over svn. Basically whatever is the easiest to comprehend and work with should be what we start people with.

...

 To undo a patch, you can revert **all** changes made in your checkout::

-    svn revert -R . +    hg revert --all +

Or "hg revert -a", which is nicer to type.

I prefer being explicit over implicit in the tutorial.

On Sun, Feb 6, 2011 at 12:36, Brendan Cully wrote:

On Sunday, 06 February 2011 at 12:13, Brett Cannon wrote:

...

On Sun, Feb 6, 2011 at 08:15, Antoine Pitrou wrote:

...

On Sun, 06 Feb 2011 02:10:15 +0100 brett.cannon wrote:

...

 To create your patch, you should generate a unified diff from your checkout's  top-level directory::

-    svn diff > patch.diff +    hg outgoing --path > patch.diff

Should be --patch. The problem is that it will show one several patch per changeset, which is normally not what you want (it's a pity "hg out" doesn't have an option to collapse them all).

Yeah, that is a perk of mq.

...

...

 If your work needs some new files to be added to the source tree, remember -to ``svn add`` them before generating the patch:: +to ``hg add`` them before generating the patch::

-   svn add Lib/newfile.py -   svn diff > patch.diff +   hg add Lib/newfile.py +   hg outgoing --patch > patch.diff

You should commit before using "outgoing", otherwise the added file is not in the repo (and therefore not in the patch).

The problem with hg (and other DVCSes) is that allows for *several* local workflows, and therefore it's harder to advocate one of them in such tutorial docs. I wonder what Georg and Dirkjan suggest.

I just happened to see this message and don't really know the context -- you may not want to use any extensions here. But my 'rdiff' extension does let you create diffs between your working directory and upstream, and collapses your changesets into a single diff.

I would rather not have new hg users have to install an extension just to get a simple workflow going.

Am 07.02.2011 00:21, schrieb Nick Coghlan:

On Mon, Feb 7, 2011 at 6:53 AM, Brett Cannon wrote:

...

I would rather not have new hg users have to install an extension just to get a simple workflow going.

I may still keep my Rdiff-based FAQ entry around as an example of how to get a collapsed diff regardless of personal workflow, though.

Installing Rdiff was actually pretty easy, and I get the impression that becoming comfortable with adding the extensions that suit your personal workflow is a key part in getting Mercurial to really work for you. We won't do people any favours if we try to pretend that isn't the case.

This is quite true. (And after a while, the same goes for creating your own extensions, BTW.) Georg

On 07/02/2011 12:25, Georg Brandl wrote:

Am 07.02.2011 00:21, schrieb Nick Coghlan:

...

On Mon, Feb 7, 2011 at 6:53 AM, Brett Cannon wrote:

...

I would rather not have new hg users have to install an extension just to get a simple workflow going. I may still keep my Rdiff-based FAQ entry around as an example of how to get a collapsed diff regardless of personal workflow, though.

Installing Rdiff was actually pretty easy, and I get the impression that becoming comfortable with adding the extensions that suit your personal workflow is a key part in getting Mercurial to really work for you. We won't do people any favours if we try to pretend that isn't the case. This is quite true. (And after a while, the same goes for creating your own extensions, BTW.)

And from the description it sounds like rdiff will be very useful for our usecase. Michael

Georg

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...

-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html

On Mon, 07 Feb 2011 13:27:31 +0000 Michael Foord wrote:

On 07/02/2011 12:25, Georg Brandl wrote:

...

Am 07.02.2011 00:21, schrieb Nick Coghlan:

...

On Mon, Feb 7, 2011 at 6:53 AM, Brett Cannon wrote:

...

I would rather not have new hg users have to install an extension just to get a simple workflow going. I may still keep my Rdiff-based FAQ entry around as an example of how to get a collapsed diff regardless of personal workflow, though.

Installing Rdiff was actually pretty easy, and I get the impression that becoming comfortable with adding the extensions that suit your personal workflow is a key part in getting Mercurial to really work for you. We won't do people any favours if we try to pretend that isn't the case. This is quite true. (And after a while, the same goes for creating your own extensions, BTW.)

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. Regards Antoine.

On Mon, 07 Feb 2011 14:34:35 +0000 Michael Foord 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 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.

On Monday, 07 February 2011 at 15:46, Antoine Pitrou wrote:

On Mon, 07 Feb 2011 14:34:35 +0000 Michael Foord 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.

On Tue, Feb 8, 2011 at 05:26, Antoine Pitrou wrote:

On Sun, 6 Feb 2011 12:13:08 -0800 Brett Cannon wrote:

...

...

We could perhaps present SVN-like "work in the working copy" workflow (without local commits), and let seasoned hg users choose other workflows they like more (they don't need our help anyway).

I would rather give people some simple workflow that has some benefit over svn. Basically whatever is the easiest to comprehend and work with should be what we start people with.

Ok, I've updated the devguide to present a simple named branch-based approach. I'm not sure it is our job to *explain* hg features, so I've just given a couple of minimal instructions to get people on track.

Yep, what you wrote is what I was thinking. Enough so people can get up and going and at least a taste of what hg can do for them w/o devolving into an hg tutorial. -Brett

Regards

Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org