[Scummvm-devel] Merging the GUI branch

Vicent Marti tanoku at gmail.com
Wed Oct 8 16:52:16 CEST 2008


Hey there Max,

I didn't really know that the unified diff format was so severely
limited. Either way, the point of a Diff file was to let some other
people test the branch (mainly for compilation issues) before the
commit. I know that there are a lot of stuff that won't carry on (such
as SVN moves or properties) -- but that shouldn't be a concern because
the merge I'm going to commit is straight from my local working copy,
which has been manually merged and fixed (no patches applied!). AFAIK,
there aren't any files which have been renamed, only old ones deleted.
I made sure that they all are removed with "svn rm" and that all new
files have their properties properly set.

I'm kind of going to miss the bus, so I'll save the merge for
tomorrow, and for some more last minute complaints. Oh, and I can also
write that script to generate MSVS files this weeked... But I only
know how to program in real languages. Like Python. ;D

Talk to you tomorrow.

Vicent Martí
----------------
http://www.smartlikearoboc.com



On Wed, Oct 8, 2008 at 3:58 PM, Max Horn <max at quendi.de> wrote:
> Am Mi, 8.10.2008, 14:39, schrieb Vicent Marti:
>> Greetings people, thanks for pointing out all this.
>>
>> Begasus: The files that fail to be patched are the ones who should be
>> removed from the build altogether, but that somehow "svn diff" doesn't
>> properly define as deleted in the patch file. These can be safely
>> ignored, they aren't compiled at all if you are building with the
>> Makefile.
>
> FYI, the diff format (which includes the output of "svn diff", the
> standard "diff" tool, etc.) does not allow to specify that a file has been
> deleted, or moved. Which is why output of "svn diff" in general is not a
> great way to peform branch merges, because e.g. it looses the history of
> file moves; it also can not cope with the following scenario: you add a
> file foo.c, then delete foo.c, then add a new file with the new name. If
> you do that in your branch, this history gets lost when you perform a
> merge using a simple patch generated by "svn diff"; worse, you can get
> weird errors, similiar to what you are actually getting in your failed
> merge attempts..
>
>
> This is why in general, "svn merge" and/or "svnmerge.py" are superios when
> doing merges. Except for nasty bugs *sigh*.
>
> Anyway: You can *not* capture the full essence of all changes on a merge
> with a simple "svn diff" generated patch file. Period.
>
> Tanoku, if you renamed any files in your branch, then I'd be glad if you
> could try to emulate that when applyiny your changes to trunk. So, if you
> renamed a file A to B in your branch, then do this:
>
>  1) go to the trunk dir
>  2) svn mv A B
>  3) now apply your patch
>  4) commit
>
> Note that committing is the last step, i.e. don't rename, commit, patch,
> commit -- do it in one step.
>
>>
>> Regarding the lack of the modern theme when launching the port: The
>> theme filenames have changed in the new GUI. Make sure that you have
>> the "scummodern.zip" file somewhere where the executable can access it
>> (e.g. same folder as the exe or in the themes path that you defined on
>> the settings) and then remove your old scummvm.ini or just manually
>> select the modern theme from the options menu. It will load
>> automatically from there on.
>>
>> I have just added a small hotfix which will automatically set ScummVM
>> to use the new modern theme if it finds a reference to the old theme
>> on the ini file.
>
> Actually, we might want to consider changing the way we reference themes
> in the config file... (using just a file basename, w/o extension and path
> details, means but that's another matter.
>
>>
>> md5: I have fixed most of your nitpicks. I do believe that the removal
>> of drawing hints in all files is correct, since most of them were
>> superfluous because of default values. I'll look into it more
>> carefully. Unfortunately, I don't have access to a Windows computer
>> right now, and I can't run batch files on my MacBook. Hopefully a kind
>> soul will update the MSVS solutions once the merge is in place.
>
> Actually, it would be nice if somebody wrote a Perl script which just
> generates all MSVC files from our module.mk files. It looks simple enough
> :)
>
>
>
> Cheers,
> 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
>




More information about the Scummvm-devel mailing list