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

[Martin Voelkle]

On 3/29/06, Bradley Arsenault <address@hidden> wrote:
> On 3/28/06, Martin Voelkle <address@hidden> wrote:
> > 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.
>
> Any smart person would not commit something that they know will break
> head. They will un-break head before they commit, which most of the
> time is simple, because, unlike branch and merge, there isn't likely
> to be huge code changes between the time you tart and the time you
> commit, and you are also able to simply update your code while your
> making changes, and if anything breaks, fix it immeddiettly, saving
> you time later.

You complain about merge overhead, I told you how it can be avoided.
And now you come with the overhead of having to develop features in a
way that every time you commit something you must put it in a state
where it doesn't break anything (and the most simple thing to do is
not commiting until the feature is finished).

> Following this logic, anytime you update, and start working, you are
> "branching" into your own code, and you are able to keep up with other
> changes. It seems perfectly reasnoble to keep your "branch" locally
> for lonhg periods of time while you work on it, and only updating
> other changes when you desire.

It doesn't seem reasonable at all to keep your work private (meaning
only you can work on it) and without any history tracking for it.
There are reasons people are moving to decentralised SCMs. I explained
them, and they're not because they fail to understand that CVS does
the job.

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

Sorry, that was a typo. It should have read: since they [new
distributed SCMs] appeared, you no longer have reasons to be afraid of
branching.

Martin