Re: Subversion 1.4 Merge badness
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
> 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 <firstname.lastname@example.org>
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