[GEM-dev] off to new shores...

[zmoelnig at iem.at]

Zitiere chris clepper <cgc at humboldtblvd.com>:

> Ok, this is very reasonable, and the only question is how to decide 
> what deserves a branch.  For example, I have some of the very basic 
> vertex_array stuff working with the current 0.90, so would the addition
> of this to CVS require a branch?  It does add a few items to GemState 
> and gemhead, but apart from that it's only a set of additional
> objects.

actually i do think that this is a good example for a branch.
i guess that the vertex stuff is almost done (apart from testing), so you would
just check in everything to the new branch.
some willing people would do some testing on other platforms and after this has
been settled it would merge again.
so the branch would (most probably) only exist for 1 week (looks a bit oversized...)

> 
> > therefore branches should be short-living, that is: a branch is 
> > created, development is done, the branch is merged to the main trunk
> 
> > and vanishes.
> 
> Looking at the branch you already made for 'v0_90', it appears that you
> have done opposite of what I thought you were talking about.  The 
> branch is the stable release, and the main trunk is still for 
> development?   So the answer to my question about branching for 
> vertex_arrays would be 'No', it goes in the main trunk.  Is this 
> correct?

no
i have to convince that i am not sure of everything too

it is true, that v0_90 is contradictory to whatever i have said.
i have branched v0_90 before really considering the dev-branches.

but i believe they could co-exist:
this would give us:
1) a main trunk that is "kind of stable" but where actual development is done
2) major-branches that are "really" stable, meaning: releases; they will never
be merged into the main trunk again; the only reason i have "branched" instead
of just "tagged" is for bugfixes.
3) small development branches that are merged when development stabilizes.


but i am no CVS expert and there are certainly points that are doubled by this
system.


> 
> > but of course, if your CVS setup cannot handle this, all discussion is
> 
> > void (but really, i cannot believe it)
> 
> I have the usual CVS command line tools at my disposal; however, I use
> 
> the integrated CVS features in Apple's IDE, which make browsing through
> 
> versions, comparing and committing changes available in the same window
> 
> as file editing.  I haven't found out how it deals with branches, and 
> it looks like they aren't even noted in the browsing and comparison 
> functions.
> 
> If the majority of new adds and commits will still be done in the main
> 
> trunk and only bugfixes and merges happen to the stable branch, then 
> this won't be a problem at all.
> 
> > and of course: each branching and merging should be properly announced
> 
> > to this list.
> 
> I think you are the only developer who can actually branch and merge in
> 
> the CVS repository right?  So there will have to be discussion before 
> any action if another developer wants to do this.

oh, i haven't thought so.
i am quite sure that every developer has the possibility to branch; right now
almost all branches have been done by me (but guenther has made one too)
about merging i have no idea but probably it is the same.
if only "managers" have the right to branch/merge i think all of us (all ? only
core developers?) should get these rights.

my proposal would be: let's try it out with the vertex-stuff.
if it turns out to be completely nonsense and/or too complicated we could drop
it again.


mfg.ads.r
IOhannes

PS: we are trying to organize some kind of meeting in Graz in late september;
nothing is fixed yet, but if we raise enough money i hope we can invite all of
you to discuss such (and other) things. more to come in separate mails