Skip to Content.
Sympa Menu

sm-discuss - [SM-Discuss] sorcery stuff

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Andrew <afrayedknot AT thefrayedknot.armory.com>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: [SM-Discuss] sorcery stuff
  • Date: Fri, 14 May 2004 10:46:48 -0700

I have two things to bring up,

1) I want to get a new stable sorcery out
2) I want to make some infrastructure changes to our scm hierarchy

Devel sorcery has had some pretty good stuff added to it, including,
but not limited to cleanse, build split code, persistant variables
between files, and full depends. All of these features are rumored to
work, or at least haven't caused any regressions. There have been
basically no significant changes to the codebase in several weeks
either. So I think its time to move things forward and have sorcery 1.10.0

Now moving right along, I want to improve the way that sorcery is held
in perforce. Right we have this:
//sgl/devel/sorcery/...
//sgl/test/sorcery/...
//sgl/stable/sorcery/...
//sgl/<foobar>/sorcery/...

Thats really annoying IMO since the "devel" sorcery is lounging with
devel grimoire, its rather confusing. I think of sorcery and the grimoire
as two distinct products (which are tied together). In anycase thats a minor
concern.

What I want to bring up is that we need two things that we dont have:
project branches, and release branches.

(disclaimer: These ideas apply only to sorcery, please do not take
them out of scope to apply to the grimoire or other portions of our
distribution, you can do whatever you want there)

A project branch is a branch off of devel sorcery, where someone (or
group of people) do some experimental work on sorcery seperate from the
day to day work in the devel branch. One example would be my build split
code, while I was developing it I just kept all the work on my client and
rolled up tarballs for people to try, while I was doing this I didnt have
the luxury of allowing perforce to track my changes and revision history
(which would have been nice), also no one else could really have helped
me out, at least not under the eyes of perforce. So, branching off
of devel for major projects then merging back to devel is a good thing,
and presents little overhead, all you have to do is add to your client
view.

Whenever we make a new sorcery stable version we want to have it be a
snapshot in time, then be able to keep it in perforce, make bug fixes
on it, and maintain a seperate development track for it, we can do this
by pushing devel to a stable line, then immediatly branching the current
stable into a release branch. Bug fixes go in and can be backported back
to devel (which is good because then we get revision history). This is
as opposed to what we do now, which is march the stable tree along and
ditch the former incarnation of stable. Theres lots of disadvantages to
just having a stable branch rather than release branches for specific
releases, the main one being loss of control and version history.

Anyways, I've discussed a lot of this with Tony and he's set to make the
changes when he gets back from vacation, heres a branching map tony came
up with:

> > OK, what we need is a branching plan. Here's a sample branch diagram:
> >
> >
> >
> > proj -----------------------
> >
> > /
> >
> > devel --------------------------------------------
> >
> > \
> >
> > test ------------------------------------
> >
> > \
> >
> > stable ----------------------
> >
> > \ \ \
> >
> > r1.9 --- \ \
> >
> > \ \
> >
> > r1.10 ---- \
> >
> > \
> >
> > r1.11 ------
> >
> >
> >
> >
> >
> > So, in this structure, you'd do all your project work in "proj" all the
> >
> > maintenance of "devel" continues as before. The people working in "proj"
> >
> > must pull in changes from "devel" on a regular (i.e. DAILY) basis to make
> >
> > sure that the project work doesn't lag behind the devel codeline.
> >

The new proposed layout in the depot would look like this:

//sgl/sorcery/devel/...
//sgl/sorcery/test/...
//sgl/sorcery/stable/...
//sgl/sorcery/proj/whiz_bang_feature1/...
//sgl/sorcery/proj/whiz_bang_feature2/...
//sgl/sorcery/release/r1.9/...
//sgl/sorcery/release/r1.10/...

That will mean that all of you with sorcery in your client will need to
adjust it after tony makes the change, and if you have any files opened,
they will need to be either submitted or you'll have to manually move
them to the new location (so sayeth tony).

Baring any serious issues with this I'd like to move ahead with it around
the 25th (when tony gets back). I'll send out a reminder and formulate a wiki
about it and how to do common things like create your own project branch,
push/pull to/from devel and so forth.

Thanks
Andrew

--
__________________________________________________________________________
|Andrew D. Stitt | astitt at sourcemage.org |
|irc: afrayedknot | afrayedknot at t.armory.com |
|aim: thefrayedknot or iteratorplusplus | |
|Sorcery Team Lead, Porting Team Lead | |
|Grimoire Guru ham/smgl | ftp://t.armory.com |
|Author and Maintainer of Prometheus | |
--------------------------------------------------------------------------




Archive powered by MHonArc 2.6.24.

Top of Page