Olaf Alders <[EMAIL PROTECTED]> writes:
> regular happening. ;) I'm assuming that when 0.27 gets integrated into
> main that I'll be able to p4 sync to get the latest version?
Guys, I figure that now is a good time to introduce everyone with the
branching patterns that we're using with CAF. There are three (well four;
when will I learn to not enumerate a list before it's done :) main types of
branches:
Main: //depot/caf/main/...
This branch serves the purpose of holding the latest'n'greatest "working"
code. I quote working because minor/short term development can occur on
it providing that the coder doesn't expect to break anything or the code
will have time to be proven well before an expected release.
Dev: //depot/caf/dev/<xyz>/...
These branches are for longer lived projects where the changes will
introduce stability issues during development. Sub <xyz> for a short
descriptive word for the project. For example, there are currently two
dev branches:
[EMAIL PROTECTED]:~/p4/lpi$ p4 dirs //depot/caf/dev/\*
//depot/caf/dev/caf-auth
//depot/caf/dev/i18n
These are also meant for group efforts. There's also (this is the fourth
type) //depot/scratch/<username>/... directories for people that want to
go off on their own to work on something or for playing around.
It is possible to use sparse branching for these development branches but
I don't think it's necessary since the project is small and branches
don't incur much overhead.
The ideal way to use these branches is for the developer to pull any new
changes in from the main codeline, make sure everything works in the
development branch and then merge the new code into the main codeline.
Release: //depot/caf/rel/<version>/...
These are branches the track the real releases. Right now, we're just
doing snapshot branches for each release but they can be used to do patch
releases without having to worry about unwanted changes from the main
branch. To see which releases are available:
[EMAIL PROTECTED]:~/p4/lpi$ p4 dirs //depot/caf/rel/\*
//depot/caf/rel/0.25
//depot/caf/rel/0.26
//depot/caf/rel/0.27
The ideal way to use these branches is to only do bugfixes on the release
codeline (it's usually easier to reproduce/fix a bug against the release
that it is discovered) and to then merge them into the main codeline and
from there to active development branches and, possible, any other
supported releases. The nice thing about OSS projects, though, is that
we'd probably just cut a new release and say, "upgrade or not" and avoid
the hassle up maintaining multiple concurrently supported versions.
Diagrammatically speaking, the branches look something like this (with flow):
______ //depot/caf/rel/0.25/...
/ @
/ @ -- bug fixes move back to main codeline
/ @
---------------------------------------------> //depot/caf/main/...
\ \ \ @
\ \ - periodic updates final \ @ - more new features into
\ \ from main update \ @ main codeline
\____\____________________________\@ //depot/caf/dev/i18n/...
I hope you guys have fixed width fonts for this :)
Also, the nice thing about Perforce's "branches look like other directories"
approach means that you can have multiple branches in your workspace (no need
for one per branch) and work on code in the appropriate branch without much
monkeying around (you may have to update your workspace 'View' and 'p4 sync').
Regards,
--
g. matthew rice <[EMAIL PROTECTED]> starnix, toronto, ontario, ca
phone: 647.722.5301 x242 gpg id: EF9AAD20
http://www.starnix.com professional linux services & products
_______________________________________________
caf mailing list
[email protected]
http://list.lpi.org/cgi-bin/mailman/listinfo/caf
