[Scummvm-devel] Towards a new release branch model

[Tarek Soliman]

On Wed, Jun 01, 2011 at 12:05:48AM +0200, Michael Madsen wrote:
> > -----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.

I imagined the fixes would be either in feature branches or in a hotfix branch (if it is a quick fix that cannot wait for a release)
I guess another way of saying it would be "less messy history" but that doesn't really explain why anyone would care about history being clean. I imagine it to be obvious.

> > 
> > > 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.
I guess I am forced to think in terms of the end result from a git point of view. The same could really be applied for the argument to rebase vs merge when dealing with a push-conflict. Rebase just makes the history cleaner in that particular situation.
> 
> > 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.
Good point. Although I don't think git is substantially harder to work with. I've tested this idea with someone (I admit it was only 1 person) who knew neither git nor svn and was able to pick up git very quickly. He also picked up "bad git habits" like creating local branches that when he eventually moved back to svn he had to drop. For him, svn was harder to work with.
I think your point is still valid: switching from svn to git is not easy.
> 
> > 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.
I hope that by saying "it makes history cleaner" is good enough. If one didn't ever try to utilize history then the benefit will be less than obvious and the desire to use it little more than obsessive compulsive.
-- 
Tarek