On Tue, Dec 4, 2012 at 8:53 AM, Julian Foad <[email protected]>wrote:
> Hyrum K Wright wrote: > > > 'svn merge' appears to hang when running a simple merge: > > > > [[[ > > $ svnd merge ^/subversion/trunk/ > > ^Csubversion/svn/util.c:913: (apr_err=4) > > subversion/svn/merge-cmd.c:163: (apr_err=4) > > subversion/libsvn_client/merge.c:11856: (apr_err=4) > > subversion/libsvn_client/merge.c:11829: (apr_err=4) > > subversion/libsvn_client/merge.c:9295: (apr_err=4) > > subversion/libsvn_client/merge.c:9001: (apr_err=4) > > subversion/libsvn_client/merge.c:8762: (apr_err=4) > > subversion/libsvn_client/merge.c:8599: (apr_err=4) > > subversion/libsvn_client/merge.c:6388: (apr_err=4) > > subversion/libsvn_ra_serf/log.c:607: (apr_err=4) > > subversion/libsvn_ra_serf/util.c:819: (apr_err=4) > > subversion/libsvn_ra_serf/util.c:786: (apr_err=4) > > svn: E000004: Error running context: Interrupted system call > > ]]] > > > > This is using a trunk client build at r1416744 on Mac OS X. I also > > see the same problem using a Linux client, same vintage. It was > > unresponsive for something on the order of 5 minutes before I finally > > killed the process with the above output. > > > Hi Hyrum. I don't know if you're seeing a network/server problem or a > client inefficiency or a bit of both. I have been thinking two things > about the client merge code though: > > * It would be good to insert some feedback about what it's doing in the > time before it starts making local changes, to give the user a more > pleasant experience during a large merge. > > * I know there is room for optimization: at the moment, for example, I > believe it calculates the youngest common ancestor of the two branches more > than once (contacting the repository each time). > > > I'll see if I can reproduce a "large" merge scenario where the start-up > time is significant, and work out where the main bottleneck is. > > For your particular case, can you tell me what branch at what revision > your merge target was? > The merge target was the ev2-export branch, which was probably most recently merged around 2-3 weeks ago, so it's not incredibly out-of-date. To reproduce, you could probably just back up the branch to before the most recent merge, and go from there. > > > > I don't know enough about what's going on under the hood, but it > > appears the serf is lost. None of my CPUs are pegged, though, so it > > looks like it's just waiting on network? Hard to believe, as I've > > got a 15/5 fiber connection. > > > It could easily be the server (or the network at the server end) that's > responding slowly. Yes, this thought crossed my mind as well. I was simultaneously running the command on a Linux box and a Mac OS box, and the both started responding at roughly the same time (though I started them both at the same time). -Hyrum
