On Wed, May 20, 2009 at 02:21:54PM -0700, Brian Osmus wrote:
> It was an svn merge from a kernel vendor branch into our working branch.
Good. You're entirely right, that should work without crashing.
I've previously handled a linux kernel vendor branch with Subversion
by the way, back in the Subversion 1.4 days, for the port of Linux
to the Nintendo DS. That was before I got involved in Subversion itself.
Actually, it wasn't really "handling" a vendor branch of the kernel,
it was "create it once and never merge from upstream ever again".
Because when we tried to merge a new upstream version, which happened
to be several releases apart, it was quite a painful experience :)
It should be less painful with 1.5 though, and it's bad that 1.6 bails
out. Hopefully we can make it work nicely for 1.7.
Out of curiosity, what's your solution to updating the vendor branch
exactly? Do you use svn_load_dirs? Or svn-load? Or a custom script?
You don't replay all the tree-structure changes the kernel people make
manually, right? How often do you update the vendor branch, given that
there are many, many changes in each released version of the kernel?
Do you pull things from git? Does your solution work well when things
are moved around in the kernel source tree?
(You dropped dev@ from Cc in your reply. I suppose that happened by
accident. So I added it again, since your one-line message does not
seem to contain private information. If you drop dev@ again from the
next reply, I'll assume you did so on purpose and that you don't want
my replies to go to dev@ either.)
Stefan
> ----------------------------------------------------------------------
>
> From: Stefan Sperling <stsp_at_elego.de>
> To: C. Michael Pilato <cmpilato_at_collab.net>
> Cc: Brian Osmus <osmusb_at_yahoo.com>; dev_at_subversion.tigris.org
> Sent: Wednesday, May 20, 2009 4:16:40 PM
> Subject: Re: Memory leak with 1.6.x clients
> 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:54:54 CEST