On Sat, Feb 26, 2011 at 10:08, Barry Warsaw <barry at python.org> 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). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20110226/46aacbc0/attachment-0001.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4