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