[Python-Dev] PEP 374 (DVCS) now in reST
rasky at develer.com
Mon Jan 26 22:57:36 CET 2009
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:
More information about the Python-Dev