Re: [Python-Dev] Mercurial conversion repositories
On 2011-02-25 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. > > 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?). I know (almost) nothing about developing Python (this is my first post to this list after lurking for quite a while now), but as a regular Mercurial contributor, I think the following could be useful for you: First, get an initial clone (let's name it 'master') over the wire using: [1] $ hg clone -U ssh://h...@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 This will be fast and save space as these local 'branch clones' will share diskspace inside .hg/store by using hardlinks, and you need to do the initial slow clone over the wire only once. 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://h...@hg.python.org/cpython instead, you'd want to edit the [paths] section in the .hg/hgrc file in each of the branch repos. But of course you can also leave the default paths as they are and synchronize via the master repo (e.g. pull new changesets into master first, and then pull into the specific branch repo). [1] http://selenic.com/repo/hg/help/clone [2] http://mercurial.selenic.com/wiki/HardlinkedClones [3] http://www.selenic.com/mercurial/hgrc.5.html#paths [4] http://selenic.com/repo/hg/help/urls ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On 2011-02-26 22:06, Barry Warsaw wrote: > 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://h...@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. ;) 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. And he's quite firm on not wanting to have Mercurial touch .hg/hgrc -- with the single exception being to write a initial .hg/hgrc on 'hg clone', containing the default path with the location from where the repo was cloned. 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? >> 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. You can use 'hg paths' for that: See http://selenic.com/repo/hg/help/paths or 'hg help paths' on the command line. >> 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. I'm quite surprised indeed to read that much about Bazaar in this thread here :) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] hg extensions was Mercurial conversion repositories
On 2011-02-27 00:13, Dj Gilcrease wrote: > Branch Management > bookmarks > http://mercurial.selenic.com/wiki/BookmarksExtension Bookmarks will be in Mercurial core for Mercurial 1.8, which will be released in a few days (March 1st). So, with 1.8 it's no longer needed to enable this extension in the configuration -- the feature will be built-in. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On 2011-02-27 01:50, Barry Warsaw wrote: > 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. :) Yep. >> 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. ;) That's quite amazing. If I talk with people about that, it often turns out that they don't check the integrity of their repos. Well, hg verify *is* through and fast enough. That's good enough for me. And being slow is not sufficient to earn my trust. FWIW, be aware that Mercurial does not do integrity checks on normal operations, so chances are you will be able to use a repo that fails verify for quite a while -- without even noticing it. For example you can remove *some* file X inside .hg/store/data and continue to add history to that repo without any sign of errors, as long as the file X isn't used during the operations you do. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] of branches and heads
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
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
___
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/archive%40mail-archive.com
Re: [Python-Dev] devguide (hg_transition): Advertise hg import over patch.
On 2011-02-27 16:35, Scott Dial wrote: > On 2/27/2011 10:18 AM, Antoine Pitrou wrote: >> Well, chances are TortoiseHG comes with an UI to apply patches >> (TortoiseSVN had one), so the command-line instructions may be of >> little use to them. > > I don't believe TortoiseHG has such a feature (or I can't find it), > although if you have TortoiseSVN, you can still use that as a patch tool. TortoiseHg can import patches just fine. FWIW, we are very close to releasing TortoiseHg 2.0 (due March 1st), which ported the current Gtk based TortoiseHg to Qt (although, it was more like a rewrite :-). For the old Gtk TortoiseHg, see the online docs here: http://tortoisehg.bitbucket.org/manual/1.1/patches.html#import-patches Homepage for the Qt port: https://bitbucket.org/tortoisehg/thg/wiki/Home For people on Windows, we have beta installers for the new Qt based TortoiseHg at: https://bitbucket.org/tortoisehg/thg/downloads Feedback is welcome on thg-...@googlegroups.com or tortoisehg-disc...@lists.sourceforge.net (we moved the development list to google groups) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] devguide (hg_transition): Advertise hg import over patch.
On 2011-02-27 23:21, Neil Hodgson wrote: > Adrian Buehlmann: > >> FWIW, we are very close to releasing TortoiseHg 2.0 (due March 1st), >> which ported the current Gtk based TortoiseHg to Qt (although, it was >> more like a rewrite :-). > >I hope this is going to be fast. Here, the Workbench window [1] starts in under 2s (Windows 7 x64 on Intel Core2 Quad). As installed with the x64 msi (installs true 64 bit exe's, including 64 bit command line hg). There's quite a lot of demand loading behind the scenes. So it's fast even for repos with many changesets. [1] http://tortoisehg.bitbucket.org/manual/2.0/workbench.html (brand new first manual version by Steve was just uploaded a few minutes ago :) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] hg pull failed
On 2011-03-06 20:09, "Martin v. Löwis" wrote: >>> So, when I cloned, I should have done something like this: >>> >>> hg clone http://hg.python.org/cpython >>> hg clone cpython 3.2 >>> hg clone 3.2 3.1 >>> hg clone cpython 2.7 >>> hg clone 2.7 2.6 >>> hg clone 2.6 2.5 >>> hg clone 2.5 2.4 >>> >>> instead of cloning everything from cpython, right? >> >> You can still change the "default" entries in .hg/hgrc to point to >> your desired default location. That's the *only* thing that changes >> depending on where you clone from. > > What I often do is to add another line (below default=, or in > ~/.hgrc), so I can do > > hg pull # pulls from my local copy > hg push pydotorg # pushes directly into the remote directory > Not sure if it fits in your specific case you mention here, but Mercurial has a reserved path alias name "default-push" with special meaning: 'hg push' pushes to (1) the path defined as default-push under [paths] in .hg/hgrc (2) if default-push is not defined, to the default path (3) if neither is defined, the command aborts with an error message 'hg pull' always pulls from the default path (default-push doesn't matter for pull). (Same for the outgoing/incoming commands.) http://selenic.com/repo/hg/help/paths ___ 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/archive%40mail-archive.com
Re: [Python-Dev] hg diff
On 2011-03-08 09:38, "Martin v. Löwis" wrote: >> However, as Michael points out, you can have your tools generate the >> patch. For example, it shouldn't be too hard to add a dynamic patch >> generator to Roundup (although I haven't thought about the UI or the >> CPU burden). > > For Mercurial, that's more difficult than you might expect. There is "hg > incoming -p", but it has the nasty problem that it may produce > multiple patches for a single file. I didn't follow/understand closely/completely what your problems is, but I wouldn't be surprised if mercurial's 'incoming' command has its limitations (it's most likely intentional, since remote inspection is limited on purpose and frowned upon by design). In general, you have to have all the changesets in a local repo to enjoy the full power of mercurial's history inspection tools. Maybe the following trick could be interesting for you: If you don't want to do an outright pull from a (possibly dubious) remote repo into your precious local repo yet, you can instead "superimpose" a separate overlay bundle file on your local repo. Example (initial step): $ cd cpython $ hg -q incoming --bundle in.hg 68322:8947c47a9fef 68323:a7e0cff05597 68324:88bbc574cfb0 68325:c43d685e1533 68326:a69ef22b60e3 68327:770d45d22a40 Now, you have a mercurial bundle file named "in.hg" which contains all these incoming changes, but -- of course -- the changes haven't yet been added to the repo. The interesting thing is, you can now superimpose this bundle on your repo, which has the effect that the aggregate is treated as if the changes had already been pulled. Continuing my example, let's now specify the bundle "in.hg" as an *overlay* by using the option -R/--repository [1]: $ hg -R in.hg log -r tip changeset: 68327:770d45d22a40 branch: 2.7 tag: tip parent: 68321:d9cc58f93d72 user:Benjamin Peterson <...> date:Mon Mar 07 22:50:37 2011 -0600 summary: transform izip_longest #11424 The fun thing with overlay bundles is: you have the full power of all mercurial history inspection commands as if the changesets had already been added to your repo. As an added extra bonus, you can later unbundle the bundle into your repo without another network round trip -- assuming you are pleased with what you've seen coming in: $ hg unbundle in.hg adding changesets adding manifests adding file changes added 6 changesets with 6 changes to 3 files (run 'hg update' to get a working copy) BTW, we regularly use overlay bundles under the hood of TortoiseHg. [1] 'hg help -v' says: global options: -R --repository REPOrepository root directory or name of overlay bundle file ___ 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/archive%40mail-archive.com
Re: [Python-Dev] hg diff
On 2011-03-08 10:53, Adrian Buehlmann wrote: > On 2011-03-08 09:38, "Martin v. Löwis" wrote: >>> However, as Michael points out, you can have your tools generate the >>> patch. For example, it shouldn't be too hard to add a dynamic patch >>> generator to Roundup (although I haven't thought about the UI or the >>> CPU burden). >> >> For Mercurial, that's more difficult than you might expect. There is "hg >> incoming -p", but it has the nasty problem that it may produce >> multiple patches for a single file. > > I didn't follow/understand closely/completely what your problems is, but > I wouldn't be surprised if mercurial's 'incoming' command has its > limitations (it's most likely intentional, since remote inspection is > limited on purpose and frowned upon by design). > > In general, you have to have all the changesets in a local repo to enjoy > the full power of mercurial's history inspection tools. > > Maybe the following trick could be interesting for you: > > If you don't want to do an outright pull from a (possibly dubious) > remote repo into your precious local repo yet, you can instead > "superimpose" a separate overlay bundle file on your local repo. OOPS. I failed to notice that this has already been proposed in the thread "combined hg incoming patch". Sorry for the noise. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?
On 2011-03-21 14:40, R. David Murray wrote: > On Mon, 21 Mar 2011 18:33:00 +0900, "Stephen J. Turnbull" > wrote: >> R. David Murray writes: >> > On Mon, 21 Mar 2011 14:07:46 +0900, "Stephen J. Turnbull" >> wrote: >> > > No, at best the DVCS workflow forces the developer on a branch to >> > > merge and test the revisions that will actually be added to the >> > > repository, and perhaps notice system-level anomolies before pushing. >> > >> > hg does not force the developer to test, it only forces the merge. >> >> I didn't say any VCS forces the test; I said that the workflow can (in >> the best case). That's also inaccurate, of course. I should have >> said "require", not "force". > > The workflow in svn "can" "require" this same thing: before committing, > you do an svn up and run the test suite. But with svn you have to redo the test after the commit *if* someone else committed just before you in the mean time, thereby changing the preconditions "behind your back", thus creating a different state of the tree compared to the state in which it was at the time you ran your test. With a DVCS, you can't push in that situation. At least not without creating a new head (which would require --force in Mercurial). ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
On 2011-03-22 11:19, John Arbash Meinel wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 3/21/2011 9:19 PM, Barry Warsaw wrote:
>> On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote:
>>
>>> Keeping the repository clean makes it easier to use a bisection search to
>>> hunt down the introduction of a bug. If every developer's intermediate
>>> commits make it into the main repository, it's hard to go back to an older
>>> revision to test something, because many of the older revisions will be
>>> broken in some way.
>>
>> So maybe this gets at my earlier question about rebase being cultural
>> vs. technology, and the response about bzr having a strong sense of mainline
>> where hg doesn't.
>>
>> I don't use the bzr-bisect plugin too much, but I think by default it only
>> follows commits on the main line, unless a bisect point is identified within
>> a
>> merge (i.e. side) line. So again, those merged intermediate changes are
>> mostly ignored until they're needed.
>>
>> -Barry
>
> Bazaar is, to my knowledge, the only DVCS that has a "mainline"
> emphasis. Which shows up in quite a few areas. The defaults for 'log',
> having branch-stable revnos[1], and the 'bzr checkout' model for
> managing a mainline.
>
FWIW, Mercurial's "mainline" is the branch with the name 'default'. This
branch name is reserved, and it implies that the head with the highest
revision number from that branch will be checked out on 'hg clone'.
Which is why it makes sense to have something sensible on the default
branch in Mercurial repositories. Or inadvertent people may be surprised
when they clone ("After cloning, the files I have seem to be from a very
old state of the project, WTF?").
What's more, 'hg log' suppresses printing the line 'branch: default' for
changesets on that branch and commits after 'hg init' go into the
default branch if 'hg branch ' hasn't been used. So, the initial
branch name of a fresh working copy is 'default'.
___
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/archive%40mail-archive.com
