On 22 Mar, 13:07, Ulrich Eckhardt <eckha..._at_satorlaser.com> wrote:
> On Monday 22 March 2010, RoboJ1M wrote:
>
> >[Out of memory during merge operation]
> [...]
> > If anybody from here could offer some assistance that would be great.
> > This is our new, live SVN service. We've migrated from CVSNT and a
> > critical failure like this would be disastrous! :(
>
> The OOM is probably triggered by the sheer amount of changes it has to merge,
> IIUC correctly you are trying to merge a branch back to trunk. If you could
> merge those changes in smaller steps, each individual step would require less
> memory. For that I would try to first to only merge revisions. If there is
> such a revision that has so many changes to so many and large files that it
> already triggers the bug, you could also switch to merging single files or
> directories or maybe even merge manually and only mark the revision as
> merged.
>
> I've been using branching and merging regularly, and I've never encountered
> this problem. I'm wondering if it's not some other kind of bug you encounter,
> like e.g. an endless recursion or something like that. This could also
> manifest as OOM, but no amount of memory would fix it.
>
> > As a possible workaround, what would be the feasibility of this:
>
> > 1) Perform the merge to a working copy local on the SVN server (ubuntu
> > 8.04)
> > 2) Copy it off there and perform the rest of the merge (testing,
> > conflict resolution)
> > 3) Commit it back.
>
> > Line ending spring immediately to mind (LR not CRLF?)
>
> You could move the line ending issue by moving it back to the Ubuntu machine
> after testing it elsewhere.
>
> Good luck!
>
> Uli
>
> --
> ML:http://tortoisesvn.tigris.org/list_etiquette.html
> FAQ:http://tortoisesvn.net/faq
>
> Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
> Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
>
> **************************************************************************************
> Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
> Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
> **************************************************************************************
> Visit our website at <http://www.satorlaser.de/>
> **************************************************************************************
> Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
> E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.
> **************************************************************************************
>
> ------------------------------------------------------http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMess...
>
> To unsubscribe from this discussion, e-mail: [users-unsubscr..._at_tortoisesvn.tigris.org].
Hi,
Merge worked perfectly on Ubuntu Server 8.04 machine (RAM usage never
went above 1% of 2GB) so it's more Windows junk.
Is there not a way to check out and force DOS line endings? I'm sure
there must be, I'll look it up.
Anyway, at least I have the beginnings of a work around.
I don't quite get *WHY* there's 792 conflicted files (it's an auto
generated storage layer BTW, 4 files per table, that's why there is so
many)
Here's what I think should happen:
1) A was branched to form B (trunk) and C (branch)
2) B was changed and C needed the updates. B was merged into C.
3) C was updated more, now the changes in C and the new features need
to be merged back into B.
But the changes made in (2) overlap with (3), BUT B was already merged
into C.
I thought this would be taken into account and B just gets updated,
not this.
The only thing I can think of is that due to the fact that it doesn't
really work, we turned off our Apache/Kerberos/Active Directory
intergration and replaced it with HTTP Basic Auth.
So the changes to B in (2) were done by 'james' and the changes to C
in (3) were done by 'jneave'.
And the memory problem is blatently an infinite loop or some such
kludge.
Thanks!
James.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2463278
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-03-22 17:12:02 CET