On Thu, 29 Mar 2001, Greg Stein wrote:
> Trust is a big thing for me. If developers don't trust each other to do the
> right thing, then the whole project loses productivity. I can go on about
> this forever, but the main point here is that I feel that installing rules
> and procedures is a blatant slap in the face, saying that "you must follow
> these rules because we don't trust you."
On the other hand, there are cases in which rules allow developers immense
freedom to run wild in their own space, without worrying about adverse
affects on other developers. This freedom is what motivates me to use the
branching methodology I use in my own Perforce depot, even though I'm the
-only- developer with access to the code! I trust myself, but the rules I
impose on how I use the depot allow me to work without thinking about
-how- I'm working, but rather about -what- I'm working on.
Of course, that entire paragraph makes a bit more sense in the context of
an explanation of the branching methodology I use which is similar, but an
improvement upon, the life-cycle described in Perforce's "Software Life-
Cycle Modelling" paper at <http://www.perforce.com/perforce/life.html> . I
need to document that methodology shortly, anyway, for a colleague, and
will post a link here when I've done so.
In brief, though, every developer has a "development branch" in which they
are free to commit as frequently or infrequently as they like, and in
which they can explore, code, change, as radically as they like, without
fear of corrupting the mainline. When their development branch reaches a
point of stability (where "stability" is up to the developer and the team
to judge based on their own needs), the developer "catches up" with the
mainline (ie: integrates any changes from the mainline into the
developer's branch), then reintegrates the development branch changes into
the mainline for subsequent testing / sharing / release.
This way, there is no question of "breaking the nightly build" or
"stepping on other developers' toes". However, the SCM system's branching
mechanism has to be Supah-Fly to make this bearable. As I mentioned in a
previous post, I'm singularly unqualified to comment on svn's score in
this area :)
Actually, to satisfy my curiousity, could someone tell me if any of the
"core team" has significant experience with Perforce? I'm asking because
the general philosophy and "mental model" of Perforce is sufficiently
different from that of RCS, CVS, SourceSafe, MKS, and other "children of
RCS" that it seems a good idea to study it and mine it.
Yes, I realize I wasn't around six months ago when people were actually
-designing- all this stuff :) And, no, I'm not asking anyone to revisit
the design. I'm just wondering if anyone -is- acquainted with the Perforce
view of the world?
By way of adding to my earlier introduction, I happened upon Perforce
about four years ago when I was just about to give up on all of the SCM
systems I had used up to that point. Nothing "made sense" to me, and I had
a laundry list of features and conceptual gripes that was about to
motivate me to roll my own. I discovered Perforce and literally checked
item after item off my laundry list. It was, for me, a perfect fit, and
grows more so the more I reflect and consider how to best use it. Of
course, it -does- have warts and things I would sorely love to change, but
it lacks that crucial component: source. Which, of course, is what has
lead me to subversion, more or less (though there is an open source clone
of Perforce underway, I wasn't sufficiently moved by what I saw).
Whew. I didn't mean to ramble on this long. Please accept my apologies.
Thanks!
--
Joy-Loving * Tripp Lilley * http://stargate.eheart.sg505.net/~tlilley/
------------------------------------------------------------------------------
"Fiber makes you poop." -- From <http://www.pvponline.com/bts_studio.php3>
Received on Sat Oct 21 14:36:26 2006