Re: [glob2-devel] Thats it, we need a plan

[Martin Voelkle]

On 3/28/06, Bradley Arsenault <address@hidden> wrote:
> On 3/21/06, Martin Voelkle <address@hidden> wrote:
> > If you do it without trying, try to avoid doing it.
> > Maybe you should ask yourself this question: what does 1.0 mean for you?
> >
> > IMHO, it's about getting the quality of the game to a point where we
> > can say it's stable.
> > That implies pretty much bug squashing and reworking the map editor. I
> > know these are completely fuzzy goals, but face it: the map editor is
> > unusable. It's not about fixing it like this or like that, it's about
> > RE-doing its UI.
>
> Fuzzy goals do nothing. Just saying "fix the map editor and the game
> is perfect" does nothing. Once has to describe whats wrong, and the
> preferred solution, as a concensus. Thats what i'm trying to do.

My point is just "fix the map editor and the game is releasable",
meaning we can concentrate on other stuff with less pressure.

> > You seem to have good ideas, but from my POV, they don't seem to bring
> > us any closer to a 1.0 release. That shouldn't stop you, there is no
> > harm in doing new stuff. Branch, and merge when it's done. But I
> > really think that wishlist items should be out of a 1.0 roadmap.
>
> Branch and merge is annoying and stupid idea. Merging is a slow
> process, and especially painfull when someone changed HEAD while you
> where branching and ambuiguities arrive. In my opponion, all changes
> should go in HEAD. It saves time and effort, and it allows more than
> one person to contribute to a new area of code.

That's because you assume there is no way to track changes to HEAD
while in a branch, which is true with CVS and SVN, but absolutely
false with newer SCMs. All changes going to HEAD means no commit while
the feature is in a broken state which implies no way to be more than
1 hacking on that feature.

> > This is what sucks with CVS: branching is not as easy as it could be.
> > You can't keep track of changes in HEAD when you are working on a
> > branch. However, merging code is usually not as complicated as people
> > think it is.
>
> I have tried to merge code before, its not pretty. Branching isn't
> worth it in any way just to solve some usability issues and add a few
> menus here and there.

Again, CVS branching is a pain but it's a zero-effort with newer SCM.
So it's worth it as soon as you want to implement a feature in more
than 1 commit.

> > It's unfortunate that open projects must be finished before releasing.
> > This is due to the fact that they have been done on the HEAD branch.
> > Had we avoided that, we would not be in that position today. I think
> > it would be worth to change the source control system (that might
> > imply ditching savannah), so people can work on their enhancements
> > without holding back the HEAD branch.
>
> That is opposite of good logic. Merging is annoying and can lead to
> ambuigities quickly, as well as duplicated effort, etc.. Ditching
> savannah is also a bad idea, if anything, we should ditch savannah CVS
> and go for Savannah SVN, as SVN is much, much better than CVS, and
> savannah has that.

Duplicate effort is worse if you work on HEAD: you build your feature
privately, because commiting would break HEAD. With a branch, your
separate work is public: people can work on it. And if you can keep
track of changes in HEAD, you simply have the best of both worlds: no
hard merge and no single commit features.

You should really try newer SCMs that popped out since the bitkeeper
incident. Try bazaar-ng, darcs, codeville, mercurial, monotone or
cogito and you will see that since anesthesia was invented you no
longer have reasons to be afraid of punctures.

Martin