[Python-Dev] Mercurial conversion repositories

[R. David Murray]

On Sat, 26 Feb 2011 13:08:47 -0500, Barry Warsaw <barry at python.org> 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?  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.

> On Feb 26, 2011, at 01:49 AM, Éric Araujo wrote:
> >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.

I agree with you that I don't trust the 'svn switch' style.  I also find
it slow.  However....

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

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 can intellectually see your point about not really *needing* the stuff
for the LODs if you are only working on LOD X, but just like 'svn switch'
makes me uncomfortable, I'm just not *comfortable* not having the whole
repo in there :)

As an example, with mercurial, I feel comfortable moving directories
around and renaming them (with the help of google it took me about 1
minute to figure out how to keep the association between the repository
instances intact).  With bazaar I got in trouble trying to do that,
because the interrelationship between the working copy directories
(and their subsets of the repo?) and the master repo(?) was not clear.
I never did figure out how to make it work, I ended up starting over
with a new clone.

Now, as I get farther into learning mercurial I may well find things that
are just as confusing as I found that aspect of bazaar, but at least I
am comfortable with the outermost layer: the repo is the repo is the repo.

--
R. David Murray                                      www.bitdance.com