On Wed, May 20, 2009 at 04:57:31PM -0400, C. Michael Pilato wrote:
> Stefan Sperling wrote:
> > On Wed, May 20, 2009 at 09:45:12PM +0100, Stefan Sperling wrote:
> >>> To reproduce this issue create a new repository and check in an older
> >>> Linux Kernel 2.6 once that is done get a newer Linux Kernel 2.6 and merge
> >>> that with what you checked in. Then do the svn commit and watch top.
> >>> Notice the memory use for the process increasing rapidly as the dots are
> >>> displayed by the process. In my case, OOM killed the process with a -9.
> >> How are you doing this? Are you adding the entire Linux source tree to
> >> the working copy and then try to commit it? If so, this is a really a
> >> use case where, according to issue #1964, svn import should be used
> >> instead of svn add, *by design* (as bad as the design may be).
> >> I am surprised that this works with 1.5.x, even.
> >
> > I didn't properly read the above paragraph you wrote before replying.
> > Sorry about that.
> >
> > So the problem is that svn bombs out while committing the result
> > of a giant merge, right? Not the result of a plain "svn add"
> > followed by "svn commit"? I.e. there is no other way of carrying
> > out the commit, and because it fails it is not possible to execute
> > the merge you want to do?
>
> Maybe "merge" in the instructions above really boils down to something like
> "untar the newer 2.6 kernel sources atop a working copy containing older 2.6
> kernel sources"? In that case, this would be merely a commit of
> (potentially many) changed files.
Yes, and maybe even many newly added files. In which case there is
no other way to carry out the merge. "svn import" won't do for that
use case.
To enhance motivation for people to look into this problem,
instead of filing a new issue, I've rescheduled issue #1964 to 1.7.0:
http://subversion.tigris.org/issues/show_bug.cgi?id=1964
Because we should definitely (at least try to) make sure that large
merges succeed before 1.7.0 is released.
Telling people to use "svn import" instead of "svn add" so we can avoid
doing the extra work to make "svn add" work for the import use case is
sort of acceptable. But we have no good workaround to suggest for merges
that fail due to many changed/added files, do we?
Thanks for the report Brian,
Stefan
Received on 2009-05-20 23:17:18 CEST