[Python-Dev] PEP 374 (DVCS) now in reST
jyasskin at gmail.com
Mon Jan 26 23:18:15 CET 2009
On Mon, Jan 26, 2009 at 2:00 PM, Guido van Rossum <guido at python.org> wrote:
> On Mon, Jan 26, 2009 at 1:57 PM, Giovanni Bajo <rasky at develer.com> wrote:
>> On Mon, 26 Jan 2009 10:31:55 -0800, Guido van Rossum wrote:
>>> On Mon, Jan 26, 2009 at 8:08 AM, Paul Hummer <paul at eventuallyanyway.com>
>>>> At a previous employer, we had this same discussion about switching to
>>>> a DVCS, and the time and cost required to learn the new tool. We
>>>> switched to bzr, and while there were days where someone got lost in
>>>> the DVCS, the overall advantages with merging allowed that cost to be
>>>> offset by the fact that merging was so cheap (and we merged a lot).
>>>> That's a big consideration to be made when you're considering a DVCS.
>>>> Merges in SVN and CVS can be painful, where merging well is a core
>>>> feature of any DVCS.
>>> I hear you. I for one have been frustrated (now that you mention it) by
>>> the inability to track changes across merges. We do lots of merges from
>>> the trunk into the py3k branch, and the merge revisions in the branch
>>> quotes the full text of the changes merged from the trunk, but not the
>>> list of affected files for each revision merged. Since merges typically
>>> combine a lot of revisions, it is very painful to find out more about a
>>> particular change to a file when that change came from such a merge --
>>> often even after reading through the entire list of descriptions you
>>> still have no idea which merged revision is responsible for a particular
>>> change. Assuming this problem does not exist in DVCS, that would be a
>>> huge bonus from switching to a DVCS!
>> Well, not only it does not exist by design in any DVCS, but I have a
>> better news: it does not exist anymore in Subversion 1.5. You just need
>> to upgrade your SVN server to 1.5, migrate your merge history from the
>> format of svnmerge to the new builtin format (using the official script),
>> and you're done: say hello to "-g/--use-merge-history", to be use with
>> svn log and svn blame.
>> This is a good writeup of the new features:
> Unfortunately I've heard we shouldn't upgrade to svn 1.5 until more
> Linux distributions ship with it by default.
Besides that, `svn merge` cannot handle parallel branches like
trunk/py3k without lots of handholding. Unlike svnmerge.py, when you
merge to and then from a branch, it tries to merge changes that came
from trunk and produces lots of conflicts. (Before you point me at
--reintegrate, note "In Subversion 1.5, once a --reintegrate merge is
done from branch to trunk, the branch is no longer usable for further
work." from the book.) In principle, the svn devs could fix this, but
they didn't in svn 1.5.
To keep this slighly on topic ... maybe the abilities and limits of
svnmerge.py and `svn merge` should be mentioned in the PEP?
More information about the Python-Dev