[Scummvm-devel] Towards a new release branch model

[Miguel Bernabeu]

>> We have our development branch ("master") and we prepare for a release
>> (simply stating our code is mature), so we branch "stable". A bug is
found
>> in "stable", so we branch for bugfix or apply directly a bugfix (quick or
>> not). At the same time we are working in new stuff on "master" _but_not_
>> bugfixing "master". Now we rebase "stable" changes onto "master", so the
>> quick fix is applied to "master" and a thorough fix can be applied later,
>> without reverting the quick fix, simply a modifying commit.

>As far as I could understand, the suggested model was to merge
>"stable" into "master", not rebase it.  Rebasing is what we do _now_,
>in the form of cherry-picking.

I'm sorry but I didn't understand completely. In my opinion cherry-picking
isn't the same as rebasing. Merging after cherry-picking is like committing
twice the same changes and in separate positions, so merge conflicts and
problems are likely. When you rebase you apply all the changes done in the
other branch to your branch as if there wasn't ever a branch. This doesn't
destroy the branch at all. Diagram:

      /-D-F     2
-A-B-C-E-G  1  Initial situation


     /-D-F-----\
-A-B-C-E-G-H  1   After merge. Commits D and F are merged in H. Where there
were 2 commits is now 1. Now we have to treat them as
                                             a whole instead of separately,
which could potentially be a PITA if there is any problem that could be
                                             addressed in one of the commits
only. Branch 2 is closed (or the same as 1).

               1
               |
-A-B-C-E-G-D-F   After rebase 1. The changes in branch 2 are applied over
the changes in branch 1. No additional commit, just
                     |                           reordering of commits. No
merge conflict possible. If you want you can merge 1 on 2 without adding
                     2                           another commit
(straight-forward merge). It looks as if all the work was done in the same
branch
                                                 instead of separate
branches. WARNING: If there is parallel work in both branches you
could have
                                                 reverted to a previous
state or created some problems.


      /-D-F         2
-A-B-C-E-G-F   1  After cherry-picking F. Commit F is applied to both
branches (it actually wouldn't be exactly the same commit to git)
                                                           Further merges
will try to apply changeset F upon changeset F providing potentially
difficult
                                                           merging
conflicts.

I don't know if it's clearer now or simply I didn't understand completely
your statement. Also, I'm not saying which is better or that there is a
better. I think there are no guarantees of problems with any approach, just
the potential. I personally prefer rebasing over merging, but I have neither
worked with a source as complex as scummvm nor with a team as big myself. I
learned git using http://progit.org/book and consult it from time to time as
I use git occasionally.

Either way the best approach is the one you are most comfortable with
because you are the ones using it and responsible for it.

Miguel

2011/5/31 Marcus Comstedt <marcus at mc.pp.se>

>
> Tarek Soliman <tarek-spam at zeusmail.bounceme.net> writes:
>
> [...]
> > When I say "this stinks of svn" I don't mean svn is inherently evil or
> immoral. I am saying the svn way is a workaround that was the best one could
> do given the crappy tool.
>
> Neither svn or git is evil or immoral, but we have a pretty good
> picture of what the best is we could do with that crappy tool (svn).
> Now we need to figure out what the best we can do with _this_ crappy
> tool (git) is, and how to get around the bits that "stink of git".  :-)
>
>
>  // Marcus
>
>
>
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is
> safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20110601/908db80e/attachment.html>