[Scummvm-devel] Towards a new release branch model

Michael Madsen michael at birdiesoft.dk
Wed Jun 1 00:05:48 CEST 2011


> -----Original Message-----
> From: Tarek Soliman [mailto:tarek-spam at zeusmail.bounceme.net]
> Sent: Tuesday, May 31, 2011 11:01 PM
> To: scummvm-devel at lists.sourceforge.net
> Subject: Re: [Scummvm-devel] Towards a new release branch model
> 
> On Tue, May 31, 2011 at 09:31:27PM +0200, Michael Madsen wrote:
> > 1) What is the concrete advantage of either of these approaches? No Git
> > terms; explain exactly what they let us do and why *we* would want to do
> > that.
> One advantage I see with doing things the proper way would be not having
> multiple commits that are the same thing.

That suggests a workflow which should avoid that problem, but no more than that. It's not an argument for release branches and hotfix branches, as Max suggested in the initial e-mail in the thread.

> 
> > 2) What, specifically, is the problem with the current approach?
> 
> - Multiple copies of a commit (even worse with multiple related commits)
> - Having an extra step to do to "port" changes
> 
> 
> About using git terms and saying stuff is bad because "it is the svn way":

Git terms are useless when arguing for a certain approach to a problem, unless that approach changes significantly *because of* Git. By keeping arguments DVCS-agnostic, it's easier to follow the *reason* for a given change.

> This is really a way of thinking that came from what we had to work with
> (svn) 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.
> Applying these workarounds to something that doesn't need them is usually
> because of tradition and doesn't make any sense technically.

That is the difference between theory and practice. I fully agree that there *are* flaws with the current approach (even though I never experience them on account of not working with the source), but at the end of the day, a bunch of people have to follow this new workflow. While a specific part of the current workflow may be less than ideal from the theoretical perspective, it does not follow that a new and improved workflow will actually be easier to work with, much like how Git is substantially harder to get started with compared to SVN.

> A lot of the advantages in using git vs using svn are proving hard for me
> to explain because you're explaining them to a svn crowd.
> Telling them "merging is faster" for example is easy for them to imagine
> but they won't even realize that because merging is faster it encourages
> making throwaway branches for "experimenting with ideas"
> Making a private branch so you can test out an idea doesn't even occur to
> someone using svn because in svn "who would ever do that?!"

That is exactly the point I'm trying to make: it's nice that you can explain what *can* be done, but you have to explain *why* that's a good thing, and in particular, you have to explain why that's a good thing *for them*. There is no such thing as a silver bullet; something which works well for you may not work for everyone else.

Michael





More information about the Scummvm-devel mailing list