On Thu, 24 Feb 2011 17:39:40 -0800 Brett Cannon wrote:

...

Your clone will contain the following branches:

$ hg branches default 68026:f12ef116dd10 3.2 68025:cef92ee1a323 2.7 68010:8174d00d0797 3.1 67955:5be8b695ea86 2.6 67287:5e26a860eded 2.5 65464:e4ecac76e499 trunk 62750:800f6c92c3ed 3.0 60075:1d05144224fe 2.4 58552:df72cac1899e 2.3 45731:a3d9a9730743 2.2 40444:d55ddc8c8501 2.1 30171:06fcccf6eca8 2.0 18214:dc0dfc9565cd

The branch "default" is the current py3k branch from SVN. The branch "trunk" represents SVN trunk history until 2.7 was branched for maintenance.

Just to help justify it in my head, the trunk branch exists for the history and nothing more, right?

True.

Could we actually close the branch so it isn't even visible by default to prevent confusing people?

Yes, we can. This can be done post-conversion, actually. Something like: $ hg up trunk $ hg ci --close-branch -m "Close trunk" Regards Antoine.

Am 25.02.2011 09:17, schrieb Dirkjan Ochtman:

On Fri, Feb 25, 2011 at 09:09, "Martin v. Löwis" wrote:

...

I think I would have liked the strategy of the PEP better (i.e. create clones for feature branches, rather than putting all in a single repository).

Unnamed heads are trivial to convert to clones.

If there are hundreds of them, it's far from trivial. I don't even know how to find out which one to convert. Regards, Martin

Am 25.02.2011 09:29, schrieb Dirkjan Ochtman:

On Fri, Feb 25, 2011 at 09:25, "Martin v. Löwis" wrote:

...

If there are hundreds of them, it's far from trivial. I don't even know how to find out which one to convert.

Right, I mostly mean it's trivial for Antoine or Georg to extract into a clone (at least that's how I was planning to do it, not sure what their idea is).

Ah ok. So I guess that goes back to my original request - that the PEP be updated. Regards, Martin

On Feb 25, 2011, at 12:09 AM, Martin v. Löwis wrote:

I think I would have liked the strategy of the PEP better (i.e. create clones for feature branches, rather than putting all in a single repository).

In my brief tests, the single repository has been easy to work with. If they were separate, it would complicate backporting patches and merges. So, I'm happy with how George and Benjamin put this together. Raymond

Hi Barry,

The way I work with the Subversion branches is to have all the active branches checked out into separate directories under a common parent, e.g.

~/projects/python/py26 ~/projects/python/py27 ~/projects/python/trunk ~/projects/python/py31 ~/projects/python/py32 ~/projects/python/py3k

This makes it very easy to just cd, svn up, make distclean, configure, make to test things. How can I do this with the hg clone when all the branches are in the single repository, but more or less hidden? After doing the 'hg clone' operation specified by Antoine, I'm left with a single cpython directory containing (iiuc) the contents of the 'default' branch.

Indeed, the default branch is checked out by default. But you can switch to another branch: $ hg sum parent: 68026:f12ef116dd10 tip In FTP.close() method, make sure to also close the socket object, not only the file. branch: default commit: (clean) update: (current) $ hg up 2.7 3310 files updated, 0 files merged, 378 files removed, 0 files unresolved $ hg sum parent: 68010:8174d00d0797 Merged revisions 88486 via svnmerge from branch: 2.7 commit: (clean) update: (current) ("hg sum" is a shorthand for "hg summary") Furthermore, once you have a local clone, you can clone it further to get several independent clones, and keep each of them updated on whatever branch you want. This makes it easy to replicate your workflow (by having a "master clone" - a mirror if you want - and then child clones that get updated from the master clone by running "hg pull").

I'm sure I'm not the only one who works this way with Subversion. IWBN to cover this in the devguide (or is it there and I missed it?).

Use of "hg update" to switch between branches is mentioned in http://potrou.net/hgdevguide/setup.html#getting-the-source-code and also http://potrou.net/hgdevguide/coredev.html#read-write-checkout and also in http://potrou.net/hgdevguide/committing.html#porting-within-a-major-version. But a dedicated FAQ entry could be added. Regards Antoine.

On 25.02.2011 17:31, Georg Brandl wrote:

On 25.02.2011 17:12, Barry Warsaw wrote:

...

On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote:

...

On Feb 25, 2011, at 12:09 AM, Martin v. Löwis wrote:

...

I think I would have liked the strategy of the PEP better (i.e. create clones for feature branches, rather than putting all in a single repository).

In my brief tests, the single repository has been easy to work with. If they were separate, it would complicate backporting patches and merges. So, I'm happy with how George and Benjamin put this together.

The way I work with the Subversion branches is to have all the active branches checked out into separate directories under a common parent, e.g.

~/projects/python/py26 ~/projects/python/py27 ~/projects/python/trunk ~/projects/python/py31 ~/projects/python/py32 ~/projects/python/py3k

This makes it very easy to just cd, svn up, make distclean, configure, make to test things. How can I do this with the hg clone when all the branches are in the single repository, but more or less hidden? After doing the 'hg clone' operation specified by Antoine, I'm left with a single cpython directory containing (iiuc) the contents of the 'default' branch.

Two scenarios are possible:

* You make a clone per branch with the full history, with the current branch being different in each of those. Since "hg update" updates to the head of the current branch, this should be easy to do. When you pull from the single repo you will get changes for the other branches as well, but they will not bother you.

* You make a clone per branch, containing *only* the respective branch (with its ancestors). This is done by using "URI#branchname" as the source when cloning/pulling.

Both should work equally well, with the former giving larger repository sizes, and the latter taking somewhat longer on the initial clone.

Ah, and the latter obviously also won't work with the "hg-native" workflow (merging between the branches using hg merge). Georg

On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote:

First, get an initial clone (let's name it 'master') over the wire using: [1]

$ hg clone -U ssh://hg@hg.python.org/cpython master

Then create a hardlinked clone [2] for working in each branch, specifying the branch to check out using option -u:

$ hg clone master py26 -u 2.6 updating to branch 2.6 NNN files updated, 0 files merged, 0 files removed, 0 files unresolved

$ hg clone master py27 -u 2.7 updating to branch 2.7 NNN files updated, 0 files merged, 0 files removed, 0 files unresolved

$ hg clone master trunk -u trunk updating to branch trunk NNN files updated, 0 files merged, 0 files removed, 0 files unresolved

$ hg clone master py31 -u 3.1 updating to branch 3.1 NNN files updated, 0 files merged, 0 files removed, 0 files unresolved

$ hg clone master py32 -u 3.2 updating to branch 3.2 NNN files updated, 0 files merged, 0 files removed, 0 files unresolved

Note that each of these branch clones will initially have your local master repo as the default path [3,4]. If you'd like to have the default push/pull path to point to ssh://hg@hg.python.org/cpython instead, you'd want to edit the [paths] section in the .hg/hgrc file in each of the branch repos.

Thanks very much Adrian, this is exactly what I was looking for. It maps almost directly to my current mental model for working on Python in Subversion (and truth be told, also how I do/did it with Bazaar). It does leave me with an empty 'master' directory that I basically won't touch, though I suppose I could hide it in a dot-filename. And I have to remember to fiddle with .hg/hgrc when I clone a new branch working directory, but I guess that's mostly a one-time cost. I'll have to remember that 'hg pull' does not update the working copy by default, and eventually I'll figure out the whole merge thing. One immediate thing that I'm missing from Bazaar is that 'bzr commit' invokes my editor and always shows me a 'diff -u' in the commit message buffer. This is incredibly handy because I don't have to remember to do the diff in a different window, and I always have all the information I want right there to craft the commit message. It doesn't look like this is possible with 'hg commit' though, right? Cheers, -Barry

On 25/02/2011 20:43, Barry Warsaw wrote:

One immediate thing that I'm missing from Bazaar is that 'bzr commit' invokes my editor and always shows me a 'diff -u' in the commit message buffer. This is incredibly handy because I don't have to remember to do the diff in a different window, and I always have all the information I want right there to craft the commit message. It doesn't look like this is possible with 'hg commit' though, right?

What you are asking for is available in TortoiseHg which absolutely rocks (if you are not allergic to the idea of a graphical tool). You can even select indvidually inside a file which lines to commit or not. A bit risky but very handy when you have a few oneliners to commit or not to commit. cheers, Philippe

On Fri, Feb 25, 2011 at 13:46, Barry Warsaw wrote:

On Feb 25, 2011, at 09:04 PM, Philippe Fremy wrote:

...

What you are asking for is available in TortoiseHg which absolutely rocks (if you are not allergic to the idea of a graphical tool).

Like shellfish, bee-strings, and Perl I'm afraid. :)

...

You can even select indvidually inside a file which lines to commit or not. A bit risky but very handy when you have a few oneliners to commit or not to commit.

You mean, TortoiseHg supports incremental commits on a single file? That's kind of neat, but scary. ;)

The record extension lets regular Mercurial do that as well. I think git supports a similar thing. -Brett

-Barry

_______________________________________________ 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

On 25Feb2011 14:43, Barry Warsaw wrote: | [...] And I have to | remember to fiddle with .hg/hgrc when I clone a new branch working directory, | but I guess that's mostly a one-time cost. Hmm. Why do you need to fiddle with the hgrc? Just curious. | I'll have to remember that 'hg pull' does not update the working copy by | default, and eventually I'll figure out the whole merge thing. "hg fetch" does though. That's my usual incanation. | One immediate thing that I'm missing from Bazaar is that 'bzr commit' invokes | my editor and always shows me a 'diff -u' in the commit message buffer. This | is incredibly handy because I don't have to remember to do the diff in a | different window, and I always have all the information I want right there to | craft the commit message. It doesn't look like this is possible with 'hg | commit' though, right? CVS had that problem. I had a wrapper somewhere that masquerades as $EDITOR and writes a diff into the commit buffer as you describe. [ Digs through my hg repository... ] Ok; then it took the form of a script called "cvscommit" that set $EDITOR to the command "cvscommit-editor", wrote the diff stuff, invoked "cvs commit". That ran "cvscommit-editor", which invoked the old $EDITOR and off you went. I would think editing the hgrc to set the hg editor and using the commit hooks would streamline this for Mercurial so you could do the usual "hg commit" command without going through the outer wrapper. I'll devote a little time today, since I've missed this little hack:-( Interested? Cheers, -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ We don't just *borrow* words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary. - James D. Nicoli

On Feb 26, 2011, at 01:49 AM, Éric Araujo wrote:

Le 25/02/2011 20:43, Barry Warsaw a écrit :

...

On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote: [snip]

...

Note that each of these branch clones will initially have your local master repo as the default path [3,4]. If you'd like to have the default push/pull path to point to ssh://hg@hg.python.org/cpython instead, you'd want to edit the [paths] section in the .hg/hgrc file in each of the branch repos.

I plan on having one clone per branch but pushing and pulling from only one repository, so I don’t need to edit hgrcs.

So let's start from the basics. I want separate working directories for each active line-of-development (I'll use that term instead of "branch"), e.g. working directories containing the tip of the 2.6 LoD, 2.7, 3.1, 3.2, and 3.3. I will not be doing feature or bug development in any of these directories. They are purely for local tracking of the remote masters. Thus, I want to be able to synchronize any one of those LoDs against the remote master with one command, like I would using Subversion's 'svn up'. I clone the remote repository using the command in the devguide, so I now have a 'cpython' directory containing the history of all LoDs, but with a working directory that reflects the 'default' LoD. Now, in the parent of 'cpython', I do the following to get my separate-directory-LoDs: $ hg clone -u 2.6 cpython py26 $ hg clone -u 2.7 cpython py27 # repeat and rinse for all other active LoDs (Aside: that cpython directory still bugs me. It doesn't naturally reflect a LoD, so why do I have to stare at it? Yes, I can make it play double duty by naming it "3.3" or whatever and updating it to the 3.3 LoD, but that feels artificial.) Now I want to synchronize my local py27 directory with the state of that LoD on python.org. This is a two step process: $ cd py27 # now I want to synchronize $ (cd ../cpython && hg pull) $ hg pull -u Editing hgrc to point to hg.python.org means the sync-to-remote-master operation is one command. I could do this: $ cd py27 # now I want to synchronize $ hg pull -u ssh://hg@hg.python.org/cpython but I'm not going to remember that url every time. It wouldn't be so bad if Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar does.

Anecdote: I migrated from Subversion to Mercurial a few years ago, and found Mercurial branches very intuitive. When I saw mentions of Bazaar branches I was driven nuts by (what I saw as) the conflation between a branch and a clone. Later I understood how it made sense from the perspective of Bazaar, so I shifted my judgment from “insanely confusing” to “a particular choice that I don’t approve” <wink>.

That's funny because to my eyes, Mercurial conflates "branches" and "clones". Why a clone operation should give me the history for all lines-of-development inside a working directory for one "arbitrary" one strikes me as bizarre (pardon the pun :). I get that for folks who like the "svn switch" method of working on multiple LoDs, this probably makes a lot of sense. I don't personally like or trust that approach much though.

What I’m saying is that a lot of Bazaar terminology using “branch” does not map as-is to Mercurial. We clone a repo, we pull from a repo/clone, we have named branches (e.g. 3.2) in a repo, we have unnamed branches on one named branch. I think you know that already, since you went from using Bazaar terms applied to Mercurial to mixing terms from both (“clone a new branch working directory” → “clone a repo”, probably). I salute your willingness to learn Mercurial, considering how fluent (and fluffly) you appear to be with Bazaar.

This is an inevitable problem with trying to converse fluently about three major dVCSs and at least one or two other non-dVCSs. They all use the same words to mean vaguely similar things, but quickly get bogged down in the implementation details assigned to those words. It all makes perfect sense when you've been immersed in those technologies, but it makes discussions and comparisons exceedingly difficult. I've no doubt it's doubly painful to many people who have no prior experience with a dVCS. (Aside: Bazaar could have potentially eased these folks transition because you can use Bazaar just like you would Subversion - as a centralized VCS -- without stopping others from using it with full dVCS features on the same code base. I don't know if Mercurial offers the same flexibility.) It's a little like trying to teach Python to a Java programmer. "Object", "Class", "Instance", "Import" all mean roughly similar things, which lulls you into a false sense of understanding. We learn by holding up the new to the light of the familiar and looking for interference patterns. :)

...

I'll have to remember that 'hg pull' does not update the working copy by default,

That pull does not update is a feature: The operation between a remote repo and the local repo (the .hg directory) is separate from the operation from the local repo to the working directory. When you know that you want pull + update (like when you have a clean working directory), you use “hg pull -u”. (I don’t like the fetch command.)

Sure, I get that. Again, this feature appears odd because I have the full history of all LoDs embedded in a working directory of a single LoD. With the arrangement I outlined above (which is independent of the dVCS backing it), it makes no sense for each LoD working directory to contain all the history of all the other LoDs. In Bazaar, a "branch" is an independent LoD and it's "repository" contains only its own history. Sure, it might have identical history with other LoDs up to the point of divergence, and I have ways to efficiently share that history across multiple LoD working directories, but they are still separate and I don't need them if I don't care about them. With Mercurial, all history for all LoDs in a repository always come along for the ride.

You speak to my heart, sir. In your ~/.hgrc, under the section [ui], set “editor = path/to/mercurial/source/hgeditor” and enjoy your diffs. I use it and love it.

Great, I'll try that, thanks. One thing Mercurial and Bazaar definitely share is a wealth of magical awesomeness hidden in manpages, wiki pages, mailing list posts, people's heads, configuration files, and source code. :)

If you want to commit a subset of your local changes, I use http://mercurial.selenic.com/wiki/CrecordExtension , a curses-based diff selection UI that works like a charm.

I very rarely want to do that. It's more common (but still, IME not *that* common) to commit the changes to just a few files at a time. One thing Bazaar has that's very nice is the ability to "shelve" some changes for a time. Let's say I'm working on a bug and I want to merge your changes in or sync to the master. I can shelve some or all of my uncommitted changes, which saves them essentially out-of-the-way patch files, and then reverts my uncommitted changes. Unshelving then is the process of re-applying those patch files, and yes, resolving conflicts. This is also a great way to work when you want to do test-driven-development but need to do some exploration first. You can hack around non-TDD until you're confident of your approach, shelve all your changes, then incrementally apply them back as you write each test. I'm sure Mercurial has something equally awesome lurking about. :) -Barry

On Feb 26, 2011, at 02:05 PM, R. David Murray wrote:

On Sat, 26 Feb 2011 13:08:47 -0500, Barry Warsaw wrote:

...

$ cd py27 # now I want to synchronize $ hg pull -u ssh://hg@hg.python.org/cpython

but I'm not going to remember that url every time. It wouldn't be so bad if Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar does.

How does setting it in the hgrc differ from "remebering" it?

It's different because you don't use a familiar interface to set it (i.e hg). You have to know to hack a file to make it work. That's not awesome user interface. ;)

I've never been comfortable with the bzr --remember option because I'm never sure what it is remembering. Much easier for me to see it in a config file. But, then, that's how my brain works, and other people's will work differently.

It's easy to tell what it remembers because it's exactly what you told it to remember ;). But I guess you're talking about push and pull automatically remembering the location when none was previously set. I love that feature. And of course, bzr 'remembers' by setting a value in a config file, which of course you *could* hack if you wanted to. It's just that you don't normally have to open your editor and remember which value in which config file you have to manually modify to set the push and pull locations. I think that's a win, but YMMV. :) Oh, and 'bzr info' always tells you what the push and pull locations are.

I find bazaar's model confusing, and hg's intuitive, just like Éric. And consider that I learned bazaar before mercurial. To me, it makes perfect sense that in a DVCS the "unit" is a directory containing a repository and a working copy, and that the repository is *the* repository. That is, it has everything related to the project in it, just like the master SVN repository does (plus, since it is a DVCS, whatever I've committed locally but not pushed to the master). To have a repository that only has some of the stuff in it is, IMO, confusing. I advocated for having all the Python history in one repo partly for that reason.

I would feel better about Mercurial's if the repo where not intimately tied with a default working tree (yes, I know -U). In a sense, that's what Bazaar's shared repositories are: a place where all your history goes. In Bazaar's model though, it's not tied to a specific working tree, and it's hidden in a dot-directory. It's still kind of beside the point - this is the way Mercurial works, and I don't really mean this thread to be an in-depth comparison between the two. -Barry

On Feb 26, 2011, at 10:20 PM, Antoine Pitrou wrote:

Often (but not always), when you're wanting to do something, there's an extension for Mercurial which can be enabled ;) http://mercurial.selenic.com/wiki/ShareExtension

You sound like an iPhone commercial: "There's an app for that." :) -Barry

On Feb 26, 2011, at 11:45 PM, Adrian Buehlmann wrote:

You'd have to take this up with Mercurial's BDFL Matt. He is a strong advocate for teaching users to learn edit their .hg/hgrc files.

Well, I guess it's doubtful I'd change his mind then. :)

Regarding Bazaar: FWIW, I periodically retried the speed of 'bzr check' - and always gave up again looking at bzr due to the horrible slowness of that command. If I have to use a DVCS I want to be able to check the integrity of my clones in reasonable time. I do it with a cron job on our internal server here and I expect it to have finished checking all our repos when I get to my desk in the morning and look into my email inbox, reading the daily email with the result of the verify runs.

After all, we do have everything secured with hashes, so we can use them, don't we?

Do you know how thorough 'bzr check' is? I don't, but then I've never used it or felt the need to. ;)

...

Oh, and 'bzr info' always tells you what the push and pull locations are.

You can use 'hg paths' for that:

Nice, thanks. -Barry

On Sat, Feb 26, 2011 at 10:08, Barry Warsaw wrote:

On Feb 26, 2011, at 01:49 AM, Éric Araujo wrote:

...

Le 25/02/2011 20:43, Barry Warsaw a écrit :

...

On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote: [snip]

...

Note that each of these branch clones will initially have your local master repo as the default path [3,4]. If you'd like to have the default push/pull path to point to ssh://hg@hg.python.org/cpython instead, you'd want to edit the [paths] section in the .hg/hgrc file in each of the branch repos.

I plan on having one clone per branch but pushing and pulling from only one repository, so I don’t need to edit hgrcs.

So let's start from the basics. I want separate working directories for each active line-of-development (I'll use that term instead of "branch"), e.g. working directories containing the tip of the 2.6 LoD, 2.7, 3.1, 3.2, and 3.3. I will not be doing feature or bug development in any of these directories. They are purely for local tracking of the remote masters. Thus, I want to be able to synchronize any one of those LoDs against the remote master with one command, like I would using Subversion's 'svn up'.

For other people's benefit, LoD == line of development (I think).

I clone the remote repository using the command in the devguide, so I now have a 'cpython' directory containing the history of all LoDs, but with a working directory that reflects the 'default' LoD. Now, in the parent of 'cpython', I do the following to get my separate-directory-LoDs:

$ hg clone -u 2.6 cpython py26 $ hg clone -u 2.7 cpython py27 # repeat and rinse for all other active LoDs

That's one way of doing it.

(Aside: that cpython directory still bugs me. It doesn't naturally reflect a LoD, so why do I have to stare at it? Yes, I can make it play double duty by naming it "3.3" or whatever and updating it to the 3.3 LoD, but that feels artificial.)

It's a clone repository of CPython; the name makes perfect sense. You are focusing on what the repository happens to be updated to ATM, not the fact that the repository itself represents any and all LoDs.

Now I want to synchronize my local py27 directory with the state of that LoD on python.org. This is a two step process:

$ cd py27 # now I want to synchronize $ (cd ../cpython && hg pull) $ hg pull -u

Editing hgrc to point to hg.python.org means the sync-to-remote-master operation is one command.

I could do this:

$ cd py27 # now I want to synchronize $ hg pull -u ssh://hg@hg.python.org/cpython

but I'm not going to remember that url every time. It wouldn't be so bad if Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar does.

So does Hg: simply edit your .hgrc to have it both pull and push to the same URL. Or you can save yourself some trouble, and simply clone the repository at a specific branch: hg clone ssh://hg@hg.python.org/cpython#2.7 I believe that might even strip out other history outside the scope of the branch.

...

Anecdote: I migrated from Subversion to Mercurial a few years ago, and found Mercurial branches very intuitive. When I saw mentions of Bazaar branches I was driven nuts by (what I saw as) the conflation between a branch and a clone. Later I understood how it made sense from the perspective of Bazaar, so I shifted my judgment from “insanely confusing” to “a particular choice that I don’t approve” <wink>.

That's funny because to my eyes, Mercurial conflates "branches" and "clones". Why a clone operation should give me the history for all lines-of-development inside a working directory for one "arbitrary" one strikes me as bizarre (pardon the pun :).

Because Hg views a clone as that: a clone of the entire repository. A branch just happens to be a part of the repository. And because it is the entire repository it has to have you point somewhere, so it goes with default since a lot of people never even work somewhere other than on default.

I get that for folks who like the "svn switch" method of working on multiple LoDs, this probably makes a lot of sense. I don't personally like or trust that approach much though.

Neither do I in an svn context and why Hg does let you check out just a branch and have all pulls and pushes only go to that branch.

...

What I’m saying is that a lot of Bazaar terminology using “branch” does not map as-is to Mercurial. We clone a repo, we pull from a repo/clone, we have named branches (e.g. 3.2) in a repo, we have unnamed branches on one named branch. I think you know that already, since you went from using Bazaar terms applied to Mercurial to mixing terms from both (“clone a new branch working directory” → “clone a repo”, probably). I salute your willingness to learn Mercurial, considering how fluent (and fluffly) you appear to be with Bazaar.

This is an inevitable problem with trying to converse fluently about three major dVCSs and at least one or two other non-dVCSs. They all use the same words to mean vaguely similar things, but quickly get bogged down in the implementation details assigned to those words. It all makes perfect sense when you've been immersed in those technologies, but it makes discussions and comparisons exceedingly difficult. I've no doubt it's doubly painful to many people who have no prior experience with a dVCS.

(Aside: Bazaar could have potentially eased these folks transition because you can use Bazaar just like you would Subversion - as a centralized VCS -- without stopping others from using it with full dVCS features on the same code base. I don't know if Mercurial offers the same flexibility.)

It's a little like trying to teach Python to a Java programmer. "Object", "Class", "Instance", "Import" all mean roughly similar things, which lulls you into a false sense of understanding. We learn by holding up the new to the light of the familiar and looking for interference patterns. :)

Yes, fun isn't it? Makes me that much more glad I don't have to care about other DVCSs anymore; make the decision of which one to go through was painful partially for this reason.

...

...

I'll have to remember that 'hg pull' does not update the working copy by default,

That pull does not update is a feature: The operation between a remote repo and the local repo (the .hg directory) is separate from the operation from the local repo to the working directory. When you know that you want pull + update (like when you have a clean working directory), you use “hg pull -u”. (I don’t like the fetch command.)

Sure, I get that. Again, this feature appears odd because I have the full history of all LoDs embedded in a working directory of a single LoD.

Not single, _current_. I know you don't like the whole svn switch approach that this is like, but Hg is very much about "don't forget a thing", which is why you need to view a clone as a clone repository that you are choosing to view in a certain way at any moment in time instead of as a single branch that just happens to be carrying around the weight of other branches. Totally different approaches to VCS.

With the arrangement I outlined above (which is independent of the dVCS backing it), it makes no sense for each LoD working directory to contain all the history of all the other LoDs.

As I said above, use the #<branch> format and you skip this issue (I think).

In Bazaar, a "branch" is an independent LoD and it's "repository" contains only its own history. Sure, it might have identical history with other LoDs up to the point of divergence, and I have ways to efficiently share that history across multiple LoD working directories, but they are still separate and I don't need them if I don't care about them. With Mercurial, all history for all LoDs in a repository always come along for the ride.

...

You speak to my heart, sir. In your ~/.hgrc, under the section [ui], set “editor = path/to/mercurial/source/hgeditor” and enjoy your diffs. I use it and love it.

Great, I'll try that, thanks. One thing Mercurial and Bazaar definitely share is a wealth of magical awesomeness hidden in manpages, wiki pages, mailing list posts, people's heads, configuration files, and source code. :)

...

If you want to commit a subset of your local changes, I use http://mercurial.selenic.com/wiki/CrecordExtension , a curses-based diff selection UI that works like a charm.

I very rarely want to do that. It's more common (but still, IME not *that* common) to commit the changes to just a few files at a time. One thing Bazaar has that's very nice is the ability to "shelve" some changes for a time. Let's say I'm working on a bug and I want to merge your changes in or sync to the master. I can shelve some or all of my uncommitted changes, which saves them essentially out-of-the-way patch files, and then reverts my uncommitted changes. Unshelving then is the process of re-applying those patch files, and yes, resolving conflicts.

Hg's is the mq (Mercurial Queue) extension.

This is also a great way to work when you want to do test-driven-development but need to do some exploration first. You can hack around non-TDD until you're confident of your approach, shelve all your changes, then incrementally apply them back as you write each test. I'm sure Mercurial has something equally awesome lurking about. :)

They all have the same history from the Linux kernel for the patch queue concept. I suspect it's pretty universally implemented, just with different command names (of course as gods forbid it be consistent).

On Sat, Feb 26, 2011 at 13:30, Barry Warsaw wrote:

On Feb 26, 2011, at 12:09 PM, Brett Cannon wrote:

...

For other people's benefit, LoD == line of development (I think).

Yes. It's just a word that isn't intimately tied to the implementation details of a specific dVCS.

...

...

I clone the remote repository using the command in the devguide, so I now have a 'cpython' directory containing the history of all LoDs, but with a working directory that reflects the 'default' LoD. Now, in the parent of 'cpython', I do the following to get my separate-directory-LoDs:

$ hg clone -u 2.6 cpython py26 $ hg clone -u 2.7 cpython py27 # repeat and rinse for all other active LoDs

That's one way of doing it.

I'm sure there are many different ways of setting things up. I am totally in favor of the devguide documenting and encouraging one particular way, and I'm sure Mercurial will prove to be a flexible tool that can conform to user's preferences rather than the other way 'round.

...

...

(Aside: that cpython directory still bugs me. It doesn't naturally reflect a LoD, so why do I have to stare at it? Yes, I can make it play double duty by naming it "3.3" or whatever and updating it to the 3.3 LoD, but that feels artificial.)

It's a clone repository of CPython; the name makes perfect sense. You are focusing on what the repository happens to be updated to ATM, not the fact that the repository itself represents any and all LoDs.

No, I get all that. I'm just not sure why I should care where all the history is stored. I'm not actually going to do any coding in the cpython directory, so it just seems like a wart I have to carry around. But as I said before, this is the Mercurial Way, so be it.

...

...

Now I want to synchronize my local py27 directory with the state of that LoD on python.org. This is a two step process:

$ cd py27 # now I want to synchronize $ (cd ../cpython && hg pull) $ hg pull -u

Editing hgrc to point to hg.python.org means the sync-to-remote-master operation is one command.

I could do this:

$ cd py27 # now I want to synchronize $ hg pull -u ssh://hg@hg.python.org/cpython

but I'm not going to remember that url every time. It wouldn't be so bad if Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar does.

So does Hg: simply edit your .hgrc to have it both pull and push to the same URL.

Right, see my follow up to RDM.

...

Or you can save yourself some trouble, and simply clone the repository at a specific branch:

hg clone ssh://hg@hg.python.org/cpython#2.7

I believe that might even strip out other history outside the scope of the branch.

That might be a better way if it doesn't slurp down the entire repository history.

...

...

...

Anecdote: I migrated from Subversion to Mercurial a few years ago, and found Mercurial branches very intuitive. When I saw mentions of Bazaar branches I was driven nuts by (what I saw as) the conflation between a branch and a clone. Later I understood how it made sense from the perspective of Bazaar, so I shifted my judgment from “insanely confusing” to “a particular choice that I don’t approve” <wink>.

That's funny because to my eyes, Mercurial conflates "branches" and "clones". Why a clone operation should give me the history for all lines-of-development inside a working directory for one "arbitrary" one strikes me as bizarre (pardon the pun :).

Because Hg views a clone as that: a clone of the entire repository. A branch just happens to be a part of the repository. And because it is the entire repository it has to have you point somewhere, so it goes with default since a lot of people never even work somewhere other than on default.

Yep, I get all that. It's Mercurial's model of the world.

...

Yes, fun isn't it? Makes me that much more glad I don't have to care about other DVCSs anymore; make the decision of which one to go through was painful partially for this reason.

Lucky you! I interact with tons of projects, so I still have to deal with everything from CVS to git. This will be my first serious foray into hg, and for that I'm glad. And really, *any* dVCS is better than a non-dVCS, so I'm really happy this is finally happening, despite any initial grumbling you're reading into my posts. :)

...

...

...

...

I'll have to remember that 'hg pull' does not update the working copy by default,

That pull does not update is a feature: The operation between a remote repo and the local repo (the .hg directory) is separate from the operation from the local repo to the working directory. When you know that you want pull + update (like when you have a clean working directory), you use “hg pull -u”. (I don’t like the fetch command.)

Sure, I get that. Again, this feature appears odd because I have the full history of all LoDs embedded in a working directory of a single LoD.

Not single, _current_. I know you don't like the whole svn switch approach that this is like, but Hg is very much about "don't forget a thing", which is why you need to view a clone as a clone repository that you are choosing to view in a certain way at any moment in time instead of as a single branch that just happens to be carrying around the weight of other branches. Totally different approaches to VCS.

No really, I do get all that! I just don't like it much. Maybe it'll grow on me though.

...

...

I very rarely want to do that. It's more common (but still, IME not *that* common) to commit the changes to just a few files at a time. One thing Bazaar has that's very nice is the ability to "shelve" some changes for a time. Let's say I'm working on a bug and I want to merge your changes in or sync to the master. I can shelve some or all of my uncommitted changes, which saves them essentially out-of-the-way patch files, and then reverts my uncommitted changes. Unshelving then is the process of re-applying those patch files, and yes, resolving conflicts.

Hg's is the mq (Mercurial Queue) extension.

I think mq is more like quilt than shelve. The moral equivalents in Bazaar would probably be the loom and pipeline extensions.

...

...

This is also a great way to work when you want to do test-driven-development but need to do some exploration first. You can hack around non-TDD until you're confident of your approach, shelve all your changes, then incrementally apply them back as you write each test. I'm sure Mercurial has something equally awesome lurking about. :)

They all have the same history from the Linux kernel for the patch queue concept. I suspect it's pretty universally implemented, just with different command names (of course as gods forbid it be consistent).

Truth to that.

I've often advocated for the big three to converge on repository format and wire protocol, and for them to innovate and differentiate on ui. The models might be different enough that you couldn't do it 100%, but the existence of mapping extensions (e.g. hg-git, bzr-hg) seems to imply that they're pretty darn close.

If we had this, then all the hand wringing about which dVCS to choose would be essentially moot. You'd just pick the cli and gui clients you preferred. Really, sweating over the dVCS tool detracts from what you do care about, which is developing Python!

There is hg-git, but that is hg on top of git.

On Sat, Feb 26, 2011 at 3:09 PM, Brett Cannon wrote:

Hg's is the mq (Mercurial Queue) extension.

I prefer the hg shelve plugin (http://mercurial.selenic.com/wiki/ShelveExtension) for this, more intuitive to me

On 26.02.2011 21:49, Barry Warsaw wrote:

On Feb 26, 2011, at 01:49 AM, Éric Araujo wrote:

...

You speak to my heart, sir. In your ~/.hgrc, under the section [ui], set “editor = path/to/mercurial/source/hgeditor” and enjoy your diffs. I use it and love it.

Except it doesn't quite work the way I want it to (hg 1.6.3). It opens your editor with two files, one is the commit message and the other is the diff. (The script itself is a bit buggy too. ;)

But it's a good clue, and I've modified the default hgeditor script to get closer, and fix the bug I noticed. I basically append the diff to the temporary log message file. It's still not right though because if the diff lines aren't prepended with 'HG:', they end up in the commit message. Arg.

Oh well, I can clearly hack a more complicated script together. It's such a blindingly obvious improvement, it's too bad 'hg commit' doesn't DTRT by default.

While I understand the usefulness of the diff feature, it is not useful to everyone, e.g. those using almost exclusively ``commit -m message``. Of course it would be nice if hg made it easier (a hgrc option, for example) to do this. BTW, I had not heard of hgeditor before, and wrote a small hg extension to do what you want (with HG: prefix :) before I saw that others had already replied with hgeditor. The extension had 10 lines of code. Georg

On Mon, 28 Feb 2011 10:08:26 -0500 Barry Warsaw wrote:

...

BTW, I had not heard of hgeditor before, and wrote a small hg extension to do what you want (with HG: prefix :) before I saw that others had already replied with hgeditor. The extension had 10 lines of code.

We should find a place (i.e. repository) to stash these useful add-ons and hacks so that all Python developers can find them.

I think you can simply add them somewhere on the hg wiki: http://mercurial.selenic.com/wiki/ and then link to the pages from our own wiki, or the developer's FAQ. Regards Antoine.

On Mon, 28 Feb 2011 16:07:48 -0500 Barry Warsaw wrote:

On Feb 28, 2011, at 04:15 PM, Antoine Pitrou wrote:

...

On Mon, 28 Feb 2011 10:08:26 -0500 Barry Warsaw wrote:

...

...

BTW, I had not heard of hgeditor before, and wrote a small hg extension to do what you want (with HG: prefix :) before I saw that others had already replied with hgeditor. The extension had 10 lines of code.

We should find a place (i.e. repository) to stash these useful add-ons and hacks so that all Python developers can find them.

I think you can simply add them somewhere on the hg wiki: http://mercurial.selenic.com/wiki/ and then link to the pages from our own wiki, or the developer's FAQ.

If they're of general use to the hg community, sure. Otherwise, it might be good to have a place of our own for our own repository tools.

Well, your diff-in-the-commit-editor-window is certainly not CPython-specific ;) Regards Antoine.

As a mercurial user, I thank you for this effort! One question, where/how do I send suggestion to what to add into .hgignore file? In particular, I found these dynamically generated files after a build in Windows (3.2) that probably should be entered as .hgignore entries:

All patches should go to the bug tracker. If you host a clone somewhere, you could start publishing patches by referring to a remote repository, rather than uploading the diff. I'm curious how this DVCS thing works out for contributors. Regards, Martin

Le vendredi 04 mars 2011 à 14:03 -0800, Santoso Wijaya a écrit :

[...] publishing patches by referring to a remote repository, rather than uploading the diff.

Is this a recommended workflow at this point, or should we generate/attach patch files still? Both, for experimentation?

Pragmatically, I think we would still prefer patches, but Mercurial should make it much easier to maintain them - e.g. you can use mq (which is what Mercurial devs themselves use, actually). We can also experiment with other forms of publishing changes, but I think that would require the publisher to somehow collapses their own changesets, so that it finally amounts to reviewing a patch. In my opinion at least, it would be bad if we started integrating intermediate changesets leading to a final patch just because Mercurial allows us to do it. I think it's better if the public history line doesn't get obscured with work-in-progress changesets. Regards Antoine.

On 6 March 2011 00:44, R. David Murray wrote:

On Fri, 04 Mar 2011 13:01:02 -0800, Santoso Wijaya < santoso.wijaya@gmail.com> wrote:

...

As a mercurial user, I thank you for this effort! One question, where/how do I send suggestion to what to add into .hgignore file? In particular, I found these dynamically generated files after a build in Windows (3.2) that probably should be entered as .hgignore entries:

? PC/python_nt_d.h ? PC/pythonnt_rc_d.h

I, on the other hand, would like to see .rej and .orig removed from the ignore list. I don't like having these polluting my working directory, and 'hg status' is the easiest way to find them (if they aren't ignored).

Or if there's some way to configure my personal .hgrc to ignore those particular ignore lines, that would be fine too :)

If those were to be removed from .hgignore then there would be a high likelihood of someone doing "hg addremove" and inadvertently tracking them. The purpose of .hgignore is to prevent inadventently tracking files that shouldn't be tracked. "hg status -i" will list all ignored files that are present in your working directory. For other options, "hg help status". Tim Delaney

On Sat, Mar 5, 2011 at 5:54 AM, Tim Delaney wrote:

If those were to be removed from .hgignore then there would be a high likelihood of someone doing "hg addremove" and inadvertently tracking them. The purpose of .hgignore is to prevent inadventently tracking files that shouldn't be tracked.

If the goal is to prevent something from being committed, shouldn't the check go in a pre-commit hook instead? -- Daniel Stutzbach

On Mar 5, 2011, at 8:44 AM, Antoine Pitrou wrote:

On Sat, 5 Mar 2011 08:36:04 -0800 Daniel Stutzbach wrote:

...

On Sat, Mar 5, 2011 at 5:54 AM, Tim Delaney wrote:

...

If those were to be removed from .hgignore then there would be a high likelihood of someone doing "hg addremove" and inadvertently tracking them. The purpose of .hgignore is to prevent inadventently tracking files that shouldn't be tracked.

If the goal is to prevent something from being committed, shouldn't the check go in a pre-commit hook instead?

Well, it's more user-friendly to help "hg addremove" work as expected, rather than add hooks down the line to forbid pushing any mistakes.

I concur. Raymond

On Fri, 25 Feb 2011 19:13:49 +1100 Neil Hodgson wrote:

With hg 1.7.5 on Windows 7 I performed a non-core checkout:

hg clone http://hg.python.org/cpython

The eol extension is enabled in global settings.

Yes, please try to disable it. The issue is we have a .hgeol in the repository right now (it's in the SVN repository too), but it doesn't match the reality of on-disk files, so when you update, the eol extension tries to "fix" those files. Regards Antoine.

Antoine Pitrou:

It should now be fixed in current SVN, meaning the final conversion should be perfectly usable with the eol extension enabled.

Good.

Do you find other issues under Windows? Have you tried pushing changes?

Since I'm not a member of core developers I used a http pull and can't push: C:\u\cpython>hg push pushing to http://hg.python.org/cpython searching for changes remote: ssl required Neil

I think people should simply get used to the idea that "default" is /the/ main branch in Mercurial (*). It's even easier to remember IMHO ("trunk" sounds a bit obscure at first, for a non-native English speaker).

+1. People will recognize "trunk" as a svn think. If that doesn't clue them in, they will ask, and every other person will know. Regards, Martin

Le dimanche 27 février 2011 à 00:42 +1000, Nick Coghlan a écrit :

On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. Löwis" wrote:

...

...

I think people should simply get used to the idea that "default" is /the/ main branch in Mercurial (*). It's even easier to remember IMHO ("trunk" sounds a bit obscure at first, for a non-native English speaker).

+1. People will recognize "trunk" as a svn think. If that doesn't clue them in, they will ask, and every other person will know.

But why not choose a name where they don't even have to ask?

Doesn't "trunk" represent exactly what it is (the former SVN trunk)? Other names would probably be less exact or less precise. Regards Antoine.

On Sat, 26 Feb 2011 15:44:08 +0100 Antoine Pitrou wrote:

Le dimanche 27 février 2011 à 00:42 +1000, Nick Coghlan a écrit :

...

On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. Löwis" wrote:

...

...

I think people should simply get used to the idea that "default" is /the/ main branch in Mercurial (*). It's even easier to remember IMHO ("trunk" sounds a bit obscure at first, for a non-native English speaker).

+1. People will recognize "trunk" as a svn think. If that doesn't clue them in, they will ask, and every other person will know.

But why not choose a name where they don't even have to ask?

Doesn't "trunk" represent exactly what it is (the former SVN trunk)? Other names would probably be less exact or less precise.

Although I now admit "legacy-trunk" sounds quite accurate, and conveys a clear warning to anyone wondering if they should use it. Regards Antoine.

Am 26.02.2011 15:42, schrieb Nick Coghlan:

On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. Löwis" wrote:

...

...

I think people should simply get used to the idea that "default" is /the/ main branch in Mercurial (*). It's even easier to remember IMHO ("trunk" sounds a bit obscure at first, for a non-native English speaker).

+1. People will recognize "trunk" as a svn think. If that doesn't clue them in, they will ask, and every other person will know.

But why not choose a name where they don't even have to ask?

That could be better. Unfortunately, nobody has proposed a name that has this property and is also correct. Regards, Martin

On 26.02.2011 03:32, Nick Coghlan wrote:

On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou wrote:

...

$ hg branches default 68026:f12ef116dd10 3.2 68025:cef92ee1a323 2.7 68010:8174d00d0797 3.1 67955:5be8b695ea86 2.6 67287:5e26a860eded 2.5 65464:e4ecac76e499 trunk 62750:800f6c92c3ed 3.0 60075:1d05144224fe 2.4 58552:df72cac1899e 2.3 45731:a3d9a9730743 2.2 40444:d55ddc8c8501 2.1 30171:06fcccf6eca8 2.0 18214:dc0dfc9565cd

The branch "default" is the current py3k branch from SVN. The branch "trunk" represents SVN trunk history until 2.7 was branched for maintenance.

Would it be possible to name "trunk" as "2.x" instead? Otherwise I could see people getting confused and asking why trunk was closed, and/or not the same as "default".

Problem is, you then have 1.5.2 released from the 2.x branch :) Georg

On 27 February 2011 01:40, Nick Coghlan wrote:

On Sat, Feb 26, 2011 at 4:34 PM, Georg Brandl wrote:

...

...

Would it be possible to name "trunk" as "2.x" instead? Otherwise I could see people getting confused and asking why trunk was closed, and/or not the same as "default".

Problem is, you then have 1.5.2 released from the 2.x branch :)

In that case, "legacy-trunk" would seem clearer.

+1 Exactly what I was about to suggest. Tim Delaney

Le samedi 26 février 2011 à 08:38 -0800, Daniel Stutzbach a écrit :

On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan wrote: Would it be possible to name "trunk" as "2.x" instead? Otherwise I could see people getting confused and asking why trunk was closed, and/or not the same as "default".

Can we just get rid of "trunk" altogether? It's history is a strict subset of the 2.7 branch's history, isn't it?

Named branches are exclusive, they can't be a subset of each other ;) (in other words: 2.7 starts where trunk stops; trunk changesets are strict ancestors of 2.7) Regards Antoine.

On Sat, 26 Feb 2011 17:49:32 +0100 Éric Araujo wrote:

Le 26/02/2011 17:44, Antoine Pitrou a écrit :

...

...

Can we just get rid of "trunk" altogether? It's history is a strict subset of the 2.7 branch's history, isn't it?

Named branches are exclusive, they can't be a subset of each other ;)

Can we just use default for trunk and py3k? For the time when both trunk and py3k were active, it would create two unnamed branches on the default branch, but one merge would solve that.

IMO, a dummy merge at the tip of the default branch may confuse users looking at the history, especially if they try a graphical display of the DAG (e.g. "hg glog" or the graph page in the Web UI). Besides, it would precisely make it harder to distinguish between trunk and py3k development at the time both took place in parallel. Regards Antoine.

...

Can we just use default for trunk and py3k? For the time when both trunk and py3k were active, it would create two unnamed branches on the default branch, but one merge would solve that.

IMO, a dummy merge at the tip of the default branch may confuse users looking at the history, especially if they try a graphical display of the DAG (e.g. "hg glog" or the graph page in the Web UI).

The dummy merge would not stay long: The commits targeted at 3.3 would be its children.

Besides, it would precisely make it harder to distinguish between trunk and py3k development at the time both took place in parallel.

IIUC, there would be two parallel lines of history (unnnamed branches). Would that be hard to read? Regards

...

Named branches are exclusive, they can't be a subset of each other ;)

Actually, they can. Take the example of the Mercurial repo itself. They fix bugs in the stable branch and add features in default. When they merge stable into default and commit, default becomes a superset of stable. That is to say, someone pulling default also gets the changesets from stable that are ancestors of the merge changset. Or in other words, if you check out default, you get all bug fixes from stable. HTH

A Mercurial 'merge' http://mercurial.selenic.com/wiki/Branch is simply a creation of another changeset, which has two parents: the current tip of the branch you're working on, and the changeset you are merging with. ~/santa On Sat, Feb 26, 2011 at 10:23 AM, Barry Warsaw wrote:

On Feb 26, 2011, at 06:32 PM, Éric Araujo wrote:

...

...

...

Named branches are exclusive, they can't be a subset of each other ;)

Actually, they can. Take the example of the Mercurial repo itself. They fix bugs in the stable branch and add features in default. When they merge stable into default and commit, default becomes a superset of stable. That is to say, someone pulling default also gets the changesets from stable that are ancestors of the merge changset. Or in other words, if you check out default, you get all bug fixes from stable.

That makes sense, but correct me if I'm wrong, it's the 'merge' operation that made this happen, right? A merge essentially brings the changesets from one branch into another.

-Barry

_______________________________________________ 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/santoso.wijaya%40gmail.com

Am 26.02.2011 17:44, schrieb Antoine Pitrou:

Le samedi 26 février 2011 à 08:38 -0800, Daniel Stutzbach a écrit :

...

On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan wrote: Would it be possible to name "trunk" as "2.x" instead? Otherwise I could see people getting confused and asking why trunk was closed, and/or not the same as "default".

Can we just get rid of "trunk" altogether? It's history is a strict subset of the 2.7 branch's history, isn't it?

Named branches are exclusive, they can't be a subset of each other ;) (in other words: 2.7 starts where trunk stops; trunk changesets are strict ancestors of 2.7)

But is there a need to have any changesets in the "trunk" named branch? Couldn't the historical changesets just be in an unnamed branch, being ancestor of so many named branches? I'd like to prevent people from mistakenly committing onto the trunk, which would be easiest if trunk didn't exist at all. Regards, Martin

...

But is there a need to have any changesets in the "trunk" named branch? Couldn't the historical changesets just be in an unnamed branch, being ancestor of so many named branches?

There is no such thing as an "unnamed branch". What would "hg branches" show? An empty space?

hg branches doesn't list unnamed branches. "hg heads" omits any branch name for unnamed branches. See the cpythonextras repository for examples: changeset: 72694:e65daae6cf44 user: Antoine Pitrou date: Mon Feb 21 21:30:55 2011 +0000 summary: Try s/UINT_MAX/INT_MAX/ This is listed as a head, but not of a named branch.

...

I'd like to prevent people from mistakenly committing onto the trunk, which would be easiest if trunk didn't exist at all.

Well, the push you request in the todo should do the trick.

Yes, that would also work. However, when then somebody proposed that we may not need the trunk branch at all in the conversion result (which I still think is the case - we don't need it), I noticed that this would solve the problem in a more clean manner.

We can also call it "legacy-trunk", too :)

I think we can do better. I also dislike "hg log --only-branch default" to only go back to 2006 (to aeefba456e4d), when this revision actually does have a parent (namely, on the trunk branch, 4b41806a0326). So I would propose this attribution to branches: - everything that is ancestor of the default branch is attributed to the default branch, back to the very beginning of the repository. - Everything currently on trunk that wouldn't be on default is then attributed to the oldest branch that it is an ancestor of, in the order 2.0, 2.1, 2.2, ... 2.7. So e.g. the 2.7 branch would go back to where it branched from the 2.6 branch (after the actual creation of the 2.6 branch in svn), which would go back to where it branched from 2.5, and so on. Regards, Martin

...

changeset: 72694:e65daae6cf44 user: Antoine Pitrou date: Mon Feb 21 21:30:55 2011 +0000 summary: Try s/UINT_MAX/INT_MAX/

It's not on an unnamed branch, it's on the "default" branch (which is omitted for concision by "hg log" and other commands with a similar output).

It's probably a terminology issue, but: the changeset can't be "on" the default "branch", because the head of the default branch (called "tip", IIUC) isn't a descendant of that changeset. It's parent is changeset: 72693:d9769c8a828b user: Antoine Pitrou date: Mon Feb 21 21:25:39 2011 +0000 summary: temp branch to debug crashes on snow leopard buildbot so you have called it "temporary branch" in subversion. I got go with that term also, if "unnamed branch" is confusing.

...

I think we can do better. I also dislike "hg log --only-branch default" to only go back to 2006 (to aeefba456e4d), when this revision actually does have a parent (namely, on the trunk branch, 4b41806a0326).

I'm not convinced that small quirks of using "hg log" are important at this point. Also, you could try other options of "hg log" such as "--follow".

IIUC, --follow doesn't help. It traces history across renames and copies, which is not what I want to overcome when trying to produce the full history of the py3k branch. As for "small quirks ... important at this point": this point is the *only* chance to get it right. If you get it wrong now, we will have to deal with it forever (or rather until we switch to the next version control system). If you chose to convert in the way it currently does: fine with me, as long as the choice was deliberate (rather than coincidental).

If we called ex-trunk the same name as ex-py3k ("default"), things would probably be quite more confusing, since inspecting a changeset wouldn't tell you immediately where it comes from (2.x or 3.x development).

I would it call default only up to the point where the py3k branch was branched off trunk. All changes up to this point actually *do* belong to both branches. Python 3's history goes all the way back to 0.9, and I'm sure you can still find code in 3.2 which was written 20 years ago. Change sets created after 3.x was forked off should certainly live on a separate mercurial branch - it would be reasonable to call this branch then 2.x. Regards, Martin

On Sat, Feb 26, 2011 at 9:55 AM, Antoine Pitrou wrote:

There is no such thing as an "unnamed branch". What would "hg branches" show? An empty space?

I understand now why I was confused. I had previously read the sentence "Both Git and Mercurial support unnamed local branches." at http://mercurial.selenic.com/wiki/BranchingExplained But as I dig deeper, I see that there is only one unnamed branch, and it actually does have an implicit name: "default". It appears Mercurial supports at least three different kinds of branching: cloning (similar to Bazaar), bookmarks (similar to git), and named branches. So a named branch can contain more than one branch. Were there reasons for going with named branches over bookmarks? PEP 385 discusses only cloning and named branches. I'm just curious, not trying to start a long discussion. :-) -- Daniel Stutzbach

On Sat, 26 Feb 2011 10:40:03 -0800 Daniel Stutzbach wrote:

On Sat, Feb 26, 2011 at 9:55 AM, Antoine Pitrou wrote:

...

There is no such thing as an "unnamed branch". What would "hg branches" show? An empty space?

I understand now why I was confused. I had previously read the sentence "Both Git and Mercurial support unnamed local branches." at http://mercurial.selenic.com/wiki/BranchingExplained

But as I dig deeper, I see that there is only one unnamed branch, and it actually does have an implicit name: "default".

Ok, so beware, the term "branch" can conflate two concepts: - a path in the topology (or line of development) - a "named branch" in hg terminology So, actually, hg promotes a slightly different terminology: - a "head" is a changeset without a child in the topology - a "branch" usually means a "named branch": a set of changesets bearing the same label (e.g. "default"); that label is freely chosen by the committer at any point, and enforces no topological characteristic (even though in practice it will have, since it's the whole point from the user's perspective, and also because hg's default behaviour and concept of a "current branch" encourages it) A (named) branch can have zero, one, or several heads: - zero head: if all branch-local heads have a child in another named branch (for example, "trunk" is linearly followed by "2.7") - several heads: if several lines of development were started in this branch without bothering to give them separate names When you have several heads on a branch, you can merge them together if you want to reconcile the lines of development they represent. When you have several branches with at least one head each, you can also merge them together: you must be careful to choose which named branch the merge changeset will be part of (for example, if you want to merge "3.1" into "3.2", you will certainly want the merge changeset to be part of "3.2", otherwise "3.1" will get a lot of unwanted features ;-)). Note: a branch with zero head is marked "inactive" in "hg branches". This basically means that it has already been merged in another branch. (of course, you can still develop in that branch, which will certainly create a new head as soon as you commit your first new changeset) Regards Antoine.

On 2011-02-26 23:26, Greg Ewing wrote:

From: Antoine Pitrou

...

- a "branch" usually means a "named branch": a set of changesets bearing the same label (e.g. "default"); that label is freely chosen by the committer at any point, and enforces no topological characteristic

There are *some* topological restrictions, because hg won't let you assign a branch name that's been used before to a node unless one of its parents has that name. So you can't create two disconnected subgraphs whose nodes have the same branch name.

That's not completely correct. You *can* do that. Mercurial by default assumes you're probably in error if you are trying to create such disconnected branch name subgraphs, but you can convince it that it's really what you want by doing: hg branch --force <existing branch name> Example (glog command requires the graphlog extension enabled [1]): $ hg init a $ cd a $ echo foo > bla $ hg ci -Am1 adding bla $ hg branch b1 marked working directory as branch b1 $ hg ci -m2 $ hg branch default abort: a branch of the same name already exists (use 'hg update' to switch to it) $ hg branch --force default marked working directory as branch default $ hg ci -m3 created new head $ hg glog --template "{rev}, {branch}\n" @ 2, default | o 1, b1 | o 0, default [1] http://mercurial.selenic.com/wiki/GraphlogExtension

So, actually, hg promotes a slightly different terminology: - a "head" is a changeset without a child in the topology

So what do you call the LoD leading up to a head? (i.e. the set of changesets that are ancestors of a head and not ancestors of any other head) Regards, Martin