[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Comments on the book

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-06-03 06:08:02 CEST

On Tue, 2004-06-01 at 21:30, Gary Feldman wrote:

> > It's been exceedingly useful. A boss doesn't
> > want to hear that "copy-modify-merge is popular", they need to be told
> > why universal lock-modify-lock policies are harmful too.
> Why? What does that have to do with a Subversion User's Guide? I'll
> rephrase what I said earlier: The primary purpose of the book is how to use
> Subversion, not which methodology is better (or even how to do SCM).

Not true. The book is not a man page. It's not just "how to use a
tool." It's about "how the tool works, the philosophy behind its
design, why we think the philosophy is better than the alternative, and
how to use this philosophy to accomplish a certain type of SCM."

The audience is more than people merely looking to use a tool in a
vaccuum. If we simply said, "we use copy-modify-merge, end of story",
many readers would come to this list and say, "But *why*? I've only
ever used locking systems. Why this other weird model? Why did you
choose it?"

I don't see the utility in making the book strive for perfect
objectivity. As you said, that's a goal for a comparative research
paper on SCM strategies. The book, on the other hand, strives to get
people comfortable with just one system, and to do that effectively it
must hand out just a bit of one-sided Kool-Aid. There's no horrible
shame in that.

> I can think of several situations where it should be, but in most
> situations, it doesn't matter. There are much more significant criteria.

Granted, SCM models aren't my area of expertise. But I'd love to hear
someone argue a strong case for lock-modify-unlock. I'd love to hear a
one-sided argument for the other side. :-)

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 3 16:12:56 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.