guid considered premature

[Tom Lord <lo...@regexps.com>]

I'm glad to see resistance to an off-the-cuff GUID design.

Abstractly, a revision control repository is a collection of revions,
each of which has a name within the repository.

If you give the repository as a whole a unique name, then the two
names combine to give you a global (internet-wide) namesapce.

That, it turns out (c.f. arch) gives you 80% of distributed revision
control.

Nifty.  So GUIDs are a good thing.

But look at what they relate too: a global namespace for revisions of
projects; distributed revision control; alternative rev ctl tools
interoperating; bug and issue tracking; distribution inventorying;
peer-to-peer automated testing, .....

There's tons of implications to consider, in other words.  arch had to
jump the gate a little here and make up its own kind of GUIDs because
it can't function without them.  But even in arch-land, we acknowledge
that one of the reasons we can't call any forthcoming release 1.0 is
because there's a definate need for a bunch of smart folks to sit down
in comfortable chairs in a pleasant room for at least a few days and
talk through as many implications of the structure and interpretation
of global names as we can think of before writing up the formal spec
of their syntax and semantics.  It's really not much less serious than
DNS.

Rev ctl is f'ing important.   Please help us all take the time to do
it right.  Who, aside from ego investment, gives a crap about "svn 1.0
in three months"?   And, anyway, isn't it the ultimate ego stroke to
have svn 1.0 that is Clearly Right?


Mission Peak (Fremont, CA) turned green recently.  It must be
December, 
-t

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: guid considered premature

[Tom Lord <lo...@regexps.com>]

       The generalisms that you lament are not as empty as they seem,
       because they are shorthand for rationales which have been
       presented in this forum before -- e.g., the rationale that
       there are tons of developers (such as myself) out there who
       really really want a better CVS,

Actually, for almost as long as arch has been around, the idea of a
more CVS-like UI, or more CVS-like features extending the current UI
has been discussed by arch users and evaluators.

At this point, there are several different approaches on the table for
how to accomplish that.  None of them require changing the core
semantics of arch -- only adding new UI and (_perhaps_) providing
alternative storage mgt.

Nobody who's actually tried arch on their projects thinks these
features are a priority.  Several who currently use it report having
quickly come to prefer the current arch model.

In other words, the supposed "CVS replacement" vs "arch" dichotomy is
not really all that true.

As for the goal you state for svn and why it's a good one: Well, I
think Bob's contributions have some relevence here, especially when
combined with the recent post by jkj@sco.com ("Re: text-based
penalty...").

It is true that I tend to evaluate svn as a free software project and
in terms of its potential impacts on other free software projects and
the free software movement generally.  This isn't an anti-business or
anti-democratic perspective, but it is a perspective that favors a
global view of businesses and communities using free software.  It's a
perspective that favors a long view and that scrutinizes immediate and
future costs (monetary and social) associated with deployment.  As you
say, there are tons of developers for whom those considerations aren't
priorities.

Importantly, my perspective includes the view that you could have, if
you took my advice, a simpler system that's more sophisticated and
more fun to develop and use.



	I would jump for joy to see a stable 1.0 in three months.

Personally, I'm looking forward to Emacs 1.0.

Sorry to keep claiming the moral high ground here but it seems to be
hard to avoid, so:

"enough is enough",
-t

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: guid considered premature

[Brian Denny <br...@briandenny.net>]

Tom Lord writes:

> But you (collectively) reply with generalisms like "a project must
> stop trying to Be Everything To Everyone" and "Subversion will not be
> a failed project".  Those are great rules of thumbs, but we're not
> really making symmetric statements of opinion here.  Nobody, not even
> me, is saying "fail" or "Be Everything to Everyone".  I'm saying,
> here's a list of revision control issues you ought to be thinking
> about.

The generalisms that you lament are not as empty as they seem, because 
they are shorthand for rationales which have been presented in this 
forum before -- e.g., the rationale that there are tons of developers 
(such as myself) out there who really really want a better CVS, the 
sooner the better, period.  From what I understand, Subversion's 
raison d'etre is to be that 'better CVS'.  It may not be 'better-
enough' for you, but it's sure as heck good enough for me, and I
would jump for joy to see a stable 1.0 in three months.


-brian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: guid considered premature

[Tom Lord <lo...@regexps.com>]

	I'll respond to this, since others might be interested too.

Good.



       We need that stabilization point in order to satisfy potential
       users (and ourselves) that it's safe to replace CVS
       installations with Subversion now.

What does "safe" mean in this context?  People put huge libraries of
source under revision control, expecting the archive to last a very
long time (decades) and support a large, open-ended variety of uses.

How does the mere on-time "stability" of a particular system prove
that that system is "safe"?   Does "stability" mean you are committing
to "upwards compatible changes only" after 1.0?   If that's what it
means, how can a prospective customer decide if the functionality you're
stabilizing on is a wise selection?

All that resistence you put up to making changes to your 1.0 plans:
multiply that across a much-expanded user community, hang a lot more
of other people's investment on the significance of changes --- and
that's the degree of freedom _you're_ going to have post 1.0.

Let's suppose that, amazingly enough, sometime after 1.0, something
finally convinces you that it's wise to approach distributed revision
control by adopting arch-style naming conventions, logging mechanisms,
and changesets.

To implement those features in svn is likely to require lots of user
visible and client visible changes.  It may change the way you expect
people to organize their source within a repository.  In principle, it
can simplify your servers, protocols, and clients, though not
obviously in any strictly upward compatible way.

But it's post 1.0, now, and lots of users have started working with
assumptions about how they organize their projects and started writing
scripts based on those assumptions.  3rd party work on clients has
taken off too.  Programmers have been trained.  Books printed.  Making
this kind of change _now_ is almost like asking those users to switch
to a whole new rev ctl system -- they'd have to migrate all their
data, scrap all their scripts, and train their programmers yet again.
Good luck!



	I'm sorry if you think our current schedule is a mistake.
	But, I'm equally confident you're wrong.

It's not quite symmetric.  It's not just two bright guys staring each
other down saying "You're wrong", "No, _you're_ wrong".

I've been trying to explain what's missing int the 1.0 plans by
pointing out specific elements of the revision control problem that
are poorly addressed by the current direction of svn: technical
matters that I think you should consider when deciding your schedule.
Matters that the decisions you make now have impact on.  Elements that
can, if anything, simplify svn in several ways.

I've been advocating for a renewed design phase to examine some pretty
central issues discovered while building the arch prototype, with the
output of this phase being some formal documents.  While arch is far
from perfectly documented and explained, I think you've seen lots of
materials that make a good case for this design effort.  (I'm not just
making a general claim, "Hey, slow down guys!" -- I've pointed out
lots of specific issues and some of their implications.)

But you (collectively) reply with generalisms like "a project must
stop trying to Be Everything To Everyone" and "Subversion will not be
a failed project".  Those are great rules of thumbs, but we're not
really making symmetric statements of opinion here.  Nobody, not even
me, is saying "fail" or "Be Everything to Everyone".  I'm saying,
here's a list of revision control issues you ought to be thinking
about.

Besides, which is better:

	(a) a 1.0 that says "We worked real had on this for a while
	    and got something that works and has some nice features.
	    Then we buckled down and stablized 1.0.  Trust us, this is
	    a good design: don't you see those nice features?  CVS
	    doesn't have those!   We plan to catch-up and exceed
	    BitKeeper and other systems post 1.0 and doesn't this 1.0
	    prove we have a great `track record'?"

	(b) a 1.0 that says "We have really thought about the design
	    space of revision control systems and made some informed
	    decisions based on that.  Because we understand the design
	    space so well, we can characterize all the competing
	    systems out there quite precisely, comparing and
	    explaining their strengths and weaknesses in those terms.
	    We have clearly stated rationales for the decisions we
	    made in our system.  Most importantly, we can prove all
	    this to you because we've written up a description of the
	    design space, and captured our decisions as (largely
	    separable) formal specifications.  You don't have to trust
	    us, you can read these materials and, based on those,
	    understand for yourself why our design is so good.  You
	    can be confident that this design is going to be stable
	    and winning 10, 15...20 years from now, and that it's
	    prospects are great for further, compatible enhancement
	    and extension during that period.  Yeah, sure, we've got a
	    feature-list that blows CVS out of the water, but if
	    you're going to look deeper before making the critical
	    decision of how to manage your code, we've got the
	    materials to guide your inquiry."




    we know when to stop adding scaffolding and start filling in
    the building

A popular failure mode in public works is to undertake an ambitious
Grand Design, get a significant ways into the project, then discover
that the design is flawed or that the funding won't ever be
sufficient.  The project "completes" by brute force, but the result
isn't pretty.  A dam that was supposed to be the world's 5th largest
gets built, but the water can't ever fill it to more than 1/3 of the
intended capacity because the fault-lines were discovered late and the
fancy new concrete turns out to be more porous than expected.  One end
of the set of new bridges across the Ohio river is started 15' off
target, work has to stop because the money runs out, and for 20 years
it's known as the "bridge to nowhere".  In a dozen cities, the housing
crisis is addressed by architecting pretty (on paper) highrises for
low-income housing with all the architectural sketches showing smiling
happy people playing in the green, tree-filled courtyards -- but 20
years later Jane Jacobs figures out that these designs can't possibly
be comfortable to live in not least because, unlike traditional urban
environments, they aren't structured in such a way as to support a
healthy street life and local economy: and sure enough, the've become
dangerous, barren wastelands with depressed microeconomies: demolition
projects waiting for the funding.


-t



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: guid considered premature

[Karl Fogel <kf...@newton.ch.collab.net>]

Tom Lord <lo...@regexps.com> writes:
> Rev ctl is f'ing important.   Please help us all take the time to do
> it right.  Who, aside from ego investment, gives a crap about "svn 1.0
> in three months"?   And, anyway, isn't it the ultimate ego stroke to
> have svn 1.0 that is Clearly Right?

I'll respond to this, since others might be interested too.

The issue isn't the version number itself, of course, but the
stabilization of the code -- testing and fixing bugs rather than
adding new features -- and the designation of a well-tested release
after that process.  We need that stabilization point in order to
satisfy potential users (and ourselves) that it's safe to replace CVS
installations with Subversion now.

Naturally, that point will be labeled "1.0", since that's what people
interpret "1.0" to mean.

At a certain stage, a project must stop trying to Be Everything To
Everyone, and focus on the correctness of what it already does.  A
project that doesn't do this usually ends up in permanent Alpha and is
gradually abandoned as people realize that it will never stabilize,
even temporarily.

The Internet is littered with failed projects.  Subversion will not be
one of them, in part because we know when to stop adding scaffolding
and start filling in the building, including unsexy things like making
sure the plumbing works.

I'm sorry if you think our current schedule is a mistake.  But, I'm
equally confident you're wrong.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org