Re: [OT] commit methodology

[Greg Stein <gs...@lyra.org>]

On Thu, Mar 29, 2001 at 05:23:37PM -0600, Karl Fogel wrote:
> +1
> 
> (When I said "please don't break 'make check'" in my previous mail, I
> meant that how you do that is up to you.  Whether you run the test
> suite before every commit is your business -- a matter of personal
> policy.  Only when the rest of us start being affected do we get the
> right to nose in. :-) )

Right! :-)

>...
> Greg Stein <gs...@lyra.org> writes:
> > This is a bit off-topic for this list, but what the heck. IMO, yes, people
> > can/should be able to check in stuff according to whatever guidelines they
> > care to impose upon themselves.

Oh, and a bit of backfill here. The above comment assumes that the developer
is capable and responsible :-). Personally, I tend to always trust anybody
with commit access (which sets a bar right there), and let them do their
work as they see fit.

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."

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: [OT] commit methodology

[Greg Stein <gs...@lyra.org>]

On Fri, Mar 30, 2001 at 01:52:22AM +0000, Tripp Lilley wrote:
> 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,

Interesting thought, but I feel a bit separate. I've been drinking for
several hours now :-), so I think I'll skip the reparte and get back to the
coding that I need to be doing :-)  Suffice it to say, that I feel your
comment about how you work is still separate from the trust issue that I'm
referring to.

>...
> 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.

Actually, I've always felt SourceSafe to be quite different from RCS/CVS. It
has a model much more similar to SVN. "copy to branch"

> 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?

Somewhat. I was talking at length with a Perforce guy a few weeks ago, and
essentially told him that we were going to take away a good portion of his
customers and depress the price that they could charge for their product.
hehe... :-)

>...
> course, it -does- have warts and things I would sorely love to change, but

Please tell us about the warts, so that we don't run into them with SVN. I'm
somewhat familar with the P4 model, but anything that you can describe would
be a help.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: [OT] commit methodology

[Tripp Lilley <tl...@perspex.com>]

On 29 Mar 2001, Ben Collins-Sussman wrote:

> Tripp Lilley <tl...@perspex.com> writes:
>  
> > 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.
> 
> None of us have used Perforce really, and SVN is attempting to
> (mostly) emulate CVS's model, at least in the user interface.
> However, because of the way our repository stores trees, a
> Perforce-using acquaintance of ours has told us that our
> "branches-are-just-subdirs" model is very similar to Perforce.

That's good to hear. I mean "branches-are-just-subdirs", not "emulate
CVS's model" :) When I have cycles (hah!), I'll peer more closely at svn
and see if it might not be possible to build a system that offers
Perforce's worldview. I suspect it -won't- be "compatible" with svn (as in
one can use the same repo in either "cvs-similar" mode or
"perforce-similar" mode), but that it could at least be built upon the
same core code (the svn filesystem, the WebDAV stuff, etc.)

Ah, another research project. Thanks, folks! ;)

-- 
   Joy-Loving * Tripp Lilley  *  http://stargate.eheart.sg505.net/~tlilley/
------------------------------------------------------------------------------
  "Fiber makes you poop." -- From <http://www.pvponline.com/bts_studio.php3>

Re: [OT] commit methodology

[Ben Collins-Sussman <su...@newton.ch.collab.net>]

Tripp Lilley <tl...@perspex.com> writes:
 
> 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.

None of us have used Perforce really, and SVN is attempting to
(mostly) emulate CVS's model, at least in the user interface.
However, because of the way our repository stores trees, a
Perforce-using acquaintance of ours has told us that our
"branches-are-just-subdirs" model is very similar to Perforce.

Re: [OT] commit methodology

[Tripp Lilley <tl...@perspex.com>]

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>