[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion 1.4 Merge badness

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-04-06 16:50:54 CEST

Mark Phippard wrote:
> The merge worked correctly, so if that is all you cared about when you
> saw the subject, you can move along.
>
> I have an svn-1.5 branch in Subclipse where I copied trunk. As you
> know, in tigris.org repositories, trunk contains a www folder. I
> delete this from the branch after I created it, because the www folder
> in Subclipse is large and I did not want to check it out.
>
> Today I did a synch up merge with my trunk. The merge processed every
> file that had changed in /trunk/www before eventually "skipping" it.
> In this case, that means it downloaded 26.81 MB of binaries (according
> to TortoiseSVN) just so that it could skip them. I am attaching a
> screenshot of the TortoiseSVN output.
>
> Could merge not be "smarter" here and make the skip decision before
> downloading the actual file? It seems like it could have known the
> www folder did not exist in the branch and skipped all changes in that
> folder.
>
> Maybe the new merge algorithm Peter Lundblad is working on will be
> more efficient in areas like this?

Making merge use the old skelta + GETs style (instead of massive-REPORT +
GETs) would help. And perhaps ra_serf already does this?

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Fri Apr 6 16:51:31 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.