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

[Bradley Arsenault]

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.



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.
>
> 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
>
>
> _______________________________________________
> glob2-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/glob2-devel
>