[Scummvm-devel] Towards a new release branch model

Michael Madsen michael at birdiesoft.dk
Wed Jun 1 02:34:11 CEST 2011


> -----Original Message-----
> From: Tarek Soliman [mailto:tarek-spam at zeusmail.bounceme.net]
> Sent: Wednesday, June 01, 2011 12:33 AM
> To: scummvm-devel at lists.sourceforge.net
> Subject: Re: [Scummvm-devel] Towards a new release branch model
> 
> > 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)

That's a way to solve the problem you stated using that approach, but that doesn't mean it's the right approach, even if this is the only problem you intend to solve (I'm not sure if that is the only reason Max proposed the change to begin with, but that just makes it all the more important to get all of those reasons listed explicitly). The approach described changes quite a few things, and it's not a given that all of those changes are necessary to solve the problem.

By explaining why you consider a particular approach to be preferable, other people stand a better chance of finding flaws in your argument; perhaps you have overlooked some aspect which makes that particular approach very problematic, which they can then identify and maybe even provide an alternative.

> 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.

If someone doesn't care about the history being clean, then it's not a very good argument - from their point of view, you're changing things for no apparent reason.

However, you can go on to explain why it's a good thing to keep the history clean, and if that person needs to work with people who *do* care, then *that* can be an argument. This principle applies to other reasons for a change as well.

For that particular wording, however, you need to explain why this approach results in "less messy history". IMO, the image provided on the nvie model page still feels rather messy; removing the feature branches (as per the original proposal) and taking the presentation medium into account does help quite a bit, but I'm not convinced it's the best way to go about it. It may just be the particular layout I'm having trouble with, or my relative inexperience with these DVCS features, or my lack of knowledge about the actual problem, but that's all I have to work with here.

> > 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.

There are more factors than just the *time* spent learning a system - for example, you also have to choose the right tool for the job (in this case, workflow). Obviously, if the job requires the things Git brings to the table, then Git is of course more suitable than SVN and you'll only get yourself into trouble if you try to force your workflow onto a tool which doesn't support it.

However, while you can learn the Git equivalents to basic SVN very quickly, that, IMO, is not sufficient to learn basic Git, since Git is a DVCS, which is inherently more complicated than a VCS like SVN, and therefore provides more features which would be considered a "core" part of Git (in part because a DVCS inspires a different workflow to begin with, due to stuff like local commits).

Anyway, this part is getting a bit off-topic, so let's end that branch here and focus on the workflow.

Michael





More information about the Scummvm-devel mailing list