On Jan 26, 2009, at 5:18 PM, Jeffrey Yasskin <jyasskin at gmail.com> wrote: > 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 >>>> > >>>> wrote: >>>>> 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: >>> http://chestofbooks.com/computers/revision-control/subversion-svn/Merge- >>> Sensitive-Logs-And-Annotations-Branchmerge-Advanced-Lo.html >> >> 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? Everytime I merge with subversion, it makes me appreciate perforce's branching and merging that much more. Jesse
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4