[Scummvm-devel] Towards a new release branch model

Tarek Soliman tarek-spam at zeusmail.bounceme.net
Wed Jun 1 00:40:01 CEST 2011


On Wed, Jun 01, 2011 at 12:16:27AM +0200, A. Milburn wrote:
> On Tue, May 31, 2011 at 05:09:06PM -0500, Tarek Soliman wrote:
> > If it is decided to be merged back to develop and there exists a better fix there, a conflict may happen and be resolved.
> > If the fix isn't there yet then if/when it happens it will replace the first fix (hopefully in the same commit)
> > Either way no explicit revert commit is needed.
> 
> I don't think this is a safe assumption, if I'm understanding you correctly.
> Quick/hacky (e.g. ignoring an error or patching up data) and 'correct' fixes
> aren't necessarily going to cause conflicts when merging, and we would need
> explicit revert commits after merging in such situations, right..?

Good point. It depends.

If the quick and dirty fix is to remove code then yes (e.g. removing detection entries for wip games)

But consider the situation where the quick fix is to add a workarounds entry to sci and the real fix to make a script patch.
The same commit for the script patch would be taking out the workarounds entry. That's what I meant by not needing an explicit revert commit.

In either case it would be ideal IMHO if both the revert commit and the real fix were done as one unit.
I was initially thinking of "one unit" as "one commit" but the no-ff merge is a good way to "group" multiple commits.
-- 
Tarek




More information about the Scummvm-devel mailing list