On Sat, Feb 26, 2011 at 13:30, Barry Warsaw <ba...@python.org> 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://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. > >> > > > >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://h...@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.
_______________________________________________ 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