DVCS PEP notes

Martin Geisler mg at daimi.au.dk
Sat Jan 17 16:17:44 CST 2009


Hi Alexandre,

I was reading through the DVCS PEP and have some comments :-) I'm
sending it to the list as well since I hope others will comment too. The
document is here:

  http://docs.google.com/View?docid=dg7fctr4_40dvjkdg64

In the 'Patch Review' section the Mercurial part says:

  hg clone trunk issue0000
  cd issue0000
  # If the patch was generated using hg export, the user name of the
  # submitter is automatically recorded. Otherwise, use patch -p1 <
  # submitted.diff and commit with hg commit -u "Firstname Lastname
  # <email.address at example.com>"
  hg import submitted.diff
  # Review patch. Revert if rejected.
  cd ../trunk
  hg fetch ../issue0000
  hg push
  rm -r ../issue0000

Instead of using an extra tool (patch), you can use 'hg import
--no-commit' followed by the 'hg commit -u' as noted in the comment.
Also, 'hg fetch' relied on the fetch extension and it is not needed. You
could replace it with

  hg push http://code.python.org/...

From the clone, or just 'hg push' to send the change back to the trunk
and then another push from the trunk. If the setup section would add

  [paths]
  python = http://code.python.org/hg/trunk

to the ~/.hgrc file, then the push command from issue0000 would just be

  hg push python


The section on backporting says that

  However unlike svnmerge's merge command, transplanted patches are not
  recorded as a merge (although, there seems to be an option to do so
  which remains to be investigated).

I also don't know what the --merge option to transplant does, but I
think it is for something else. But why would one would expect a
transplanted changeset to be a merge -- it is simply a patch taken out
of its original context.

The section continues with:

  This behavior might later be annoying if the branch, where a patch was
  transplanted to, merge with the mainline or vice versa because the
  specific change might get recorded twice in the history.

which is vague. The behaviour is simple and definite: a changeset will
appear twice in the history when the merge is made. When the branch is
pulled into the mainline the two changesets will behave as any other two
changes, they just happen to have the same commit message and contain
the same changes.

Finally, when merging changes forward, it is said that

  Although this approach makes the history non-linear and slightly more
  difficult to follow, it encourages fixing bugs across all supported
  releases.

I don't think it makes the history more difficult to follow -- I am not
even sure I would mention the fact that it makes the history non-linear.
Why not just keep the part of the sentence after the final comma? Here
the non-linear history is not something to be afraid of and it reflects
the development more closely than a linear history.


The 'Separation of Issue Dependencies' section mentions the loom plugin
for bzr -- you could mention the pbranch extension for Mercurial:

  http://arrenbrecht.ch/mercurial/pbranch/


In the 'Platform/Tool Support' is says that Bazaar is the only DVCS
which supplies a Windows installer directly, whereas Mercurial relies on
a third-party. This is a shame -- could we not put the Windows binaries
on selenic.com and make them official?


In the table the Mercurial entry for "Case-insensitive filesystem
support" is not filled in. I think it should say:

  Mercurial repositories are unaffected by the case-sensitiveness of
  filesystems and can be shared between systems and architectures.
  Collisions in filenames on case-insensitive filesystem are detected on
  checkout and the operation is aborted. A developer on a case-sensitive
  filesystem can then correct the mistake.


The 'Development' section says on Python 2.6 compatibility:

  Mercurial, on the other hand, took two months to be compatible with
  its 1.1 release.

I don't like the way that sentence sounds -- it of gives the impression
that Mercurial had to be fixed a lot to work on Python 2.6. The two
months were just how the release cycle happened to work out. Mercurial
now has a time-based release plan:

  http://www.selenic.com/mercurial/wiki/index.cgi/TimeBasedReleasePlan


In the 'Special Features' section it is mentioned that Bazaar has a
stable Python scripting interface. Maybe we should mention that
Mercurial has a stable command-line interface in addition to a stable
hook system? It would be nice to at least mention Mercurial here too.

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://selenic.com/pipermail/mercurial-devel/attachments/20090117/da6b4a85/attachment.pgp 


More information about the Mercurial-devel mailing list