[Scummvm-devel] Memory consumption in GUI branch

[Oystein Eftevaag]

Yup, branch merging with SVN is indeed a complete mess, quite often :/. 
It's the primary reason we switched to Perforce at work, actually.

One thing you could try: Specifically merging each of your original 
commits to trunk, one by one.

I.e.:
1. cd /path/to/trunk/checkout
2. svn merge -r 1000:1001 https://your/branch/repository .
3. Repeat 3 for each commit that wasn't a merge from trunk.

-- 
Oystein/vinterstum

Vicent Marti wrote:
> Hey Max,
>
> I've followed those exact same steps (twice) and the result is a  
> complete mess:
>
> It looks like SVNMerge is merging all the revisions on my branch to  
> the trunk *one by one*, so for instance in a file I've developed from  
> scratch (like xmlparser.cpp), it first merges the first revision into  
> trunk, and then merges the second one on top of it creating a 
> conflict  between them. The end result is that all the files I've 
> written are  full of conflicts between their different revisions up to 
> a point that  they cannot be manually fixed.
>
> This is very strange indeed... Maybe I'm missing something obvious?  
> Maybe I trashed my branch sometime during the GSoC? That would indeed  
> suck.
>
> Cheers,
> Tanoku
>
> On Oct 5, 2008, at 10:00 PM, Max Horn wrote:
>
>  
>> Am 05.10.2008 um 20:44 schrieb Vicent Marti:
>>
>>    
>>> Fine with me. I'm willing to take all the blame when the trunk gets
>>> trashed -- it's not like you actually know my *exact* location to  bomb
>>> me or anything.
>>>       
>> That's what you *think*... :)
>>
>>    
>>> I went ahead and tried a Svnmerge on my local copy... It turned out
>>> rather bad because it showed conflicts on my own files (i.e. on files
>>> that are only on the GUI branch and not in trunk)...
>>>       
>> Here's what I did when merging the RTL branch:
>>
>> 1) Made sure there were no local modifications in both my trunk and  
>> my RTL branch checkout
>> 2) Brought the RTL branch up to speed, i.e. performed a merge on it  
>> agsinst trunk. That is:
>>  cd gsoc2008-rtl
>>  svnmerge merge -S /scummvm/trunk
>>  [ ... manual cleanup of merge conflicts: test whether it all still  
>> builds, etc. ...]
>>  svn ci -F svnmerge-commit-message.txt
>>
>> 3) Then, merged everything back to trunk, i.e.
>>  cd trunk
>>  svnmerge merge --bidirectional -S /scummvm/branches/gsoc2008-gui
>>  [ ... manual cleanup of merge conflicts, testing ...]
>>
>> 4) After I was dead sure the merge went right, I commited it with a  
>> custom merge message.
>>
>> If you tell me what problems you got precisely at which step, maybe  
>> we can work it out.
>>
>>
>>    
>>> I either did something wrong or SVNMerge is even worse than what I  had
>>> expected. Any insight on this? I was hoping for a merge on Tuesday
>>> afternoon, after I get everything sorted out. Who's going to stand up
>>> and and do some watchful guidance (and some blame sharing, while  we're
>>> at it)?
>>>       
>> I can *try* to be there, but I can promise it at this time, as I  
>> have to work hard on my thesis these days.
>>
>> Bye,
>> Max
>>     
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's 
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great 
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the 
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>