[Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

[Dirkjan Ochtman]

On Wed, Mar 23, 2011 at 04:39,  <skip at pobox.com> wrote:
>
>    Dirkjan> The right solution here is to use different clones for
>    Dirkjan> different projects/areas. The proposed interpreter/stdlib
>    Dirkjan> split, for example, might reduce contention (although I imagine
>    Dirkjan> it would reduce it only by a little bit?).
>
> How about splitting the documentation and the code into separate
> repositories (I believe that is the proper term, though perhaps "clone" is -
> Dirkjan is the expert)?

That might work. I guess the stdlib/interpreter split should also
think about how to split up the docs.

And yes, clone might be a better word to use in this context. The
repository word is slightly overloaded, in that it can be used both
for clone, or to distinguish the .hg part from the working dir part of
a clone, for example.

> Moving onto something related, but different, I find that people bandy about
> terms which I just can't seem to find defined very well anywhere I've
> looked.  The Mercurial Glossary (http://mercurial.selenic.com/wiki/Glossary)
> would seem to be the obvious place to look, but it doesn't define the terms
> "branch" or "clone" (nor does it obviously differentiate a "named branch"
> from any other kind of "branch").  I hesitate to overload those words with
> the meanings I've acquired using Subversion and CVS, because they will
> probably be wrong in subtle ways.  Also, "rebase" is not defined in the
> glossary.

One problem with branches in DVCS is that there are so many kinds of
them. The SVN repository, for example, would now be reflected by all
of the clones of python-dev lineage (starting with the same changeset)
everywhere. Each of these clones represent a branch, in the sense that
someone can commit there and thus deviate from all other repositories.
If you commit twice from the same parent changeset in your clone, you
end up with two heads (on the same named branch), which are also
separate branches in the distributed global python-dev DAG. And all of
these are "unnamed" branches, possibly residing on the same named
branch...

> There are clearly lots of Mercurial-related documents on the web.  There is
> no editorial  review of their quality other than Google page rank.  Is there a
> prioritized list of stuff one should read?

The hg wiki is a good resource, but can be a bit disorganized. You
might also want to read the hgbook, which is slightly outdated but
should have thorough explanations. It's also available in dead-tree
form.

Cheers,

Dirkjan