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

Re: when is 'shared file' section of web site updated?

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-11-06 16:37:12 CET

cmpilato@red-bean.com writes:

> I'm not interested in branching. A branch only makes sense when
> development by Sally on a given source file is expected to clash so
> often with Harry's other work

That's not the "only" use-case of branches. The other use-case is the
whole idea of maintaining both 'stable' and 'development' lines of
something.

And in this case, I would define

  stable == a line where the the book is always coherent
     dev == a line where the book may contain incomplete or
            disorganized fragments of information.
 
> My vote is for keeping things exactly as they are today, with the
> optional addition (by someone other than me) of a more regular posting
> of perhaps just the HTML version of the work-in-progress. Then Ben,
> Fitz, and I can decide on good places to snapshot the book to replace
> the less-often-updated milestone PDF, HTML and PS versions.

I guess, then, that I'm going to keep my patches to myself for a
loooong time. I write in disorganized pieces, I move things around,
make multiple passes, and so on. In the status quo, I have to be sure
to commit only things that keep the book in a perfectly coherent
state. I'd much rather commit early and often, but I don't want to
"break" the readability of the book.

The real issue here, I guess, is deciding what it exactly what it
means to present 'stability' to the world. Does it mean

 1. the book's source code is coherent?, or
 2. the compiled versions published on the web site are coherent?

If we go with #2, then yeah, I guess we just need to publish compiled
versions much less often, at specific points of stability. But then I
feel bad about blocking everyone else: "no sorry, you can't post a new
PDF, because we're not at a writing checkpoint yet." That's why I was
advocating a branch.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 6 16:39:07 2002

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

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