Ewww, let's not jump the gun on this one. Sitting down and
designing a patch format first is a much better idea IMNSHO.
If we have the time for that before 1.0 I don't know. We
certainly told Tom in the past that we didn't.
My possibly imprecise recollection is that I not only suggested
working on a changeset format, but also warned that I thought
consideration of changeset functionality would naturally lead to a
revisitation of some pretty deep elements of the svn design. So at
roughly the same time, I was proposing a "stop and have a design
review" phase.
In other words, what I was told there wasn't time for was much larger
in scope than just working on changeset formats.
So, having had some off-list interaction with some svn hackers, I have
a somewhat better feel for the multi-faceted "state" of the project
and its various interests. In that light, I would still propose a
design review phase: immediately after 1.0, concurrently with
supporting 1.0 adopters and clearing the board of the low hanging
fruit that was nonetheless pushed off to "after 1.0".
Between now and then: can/should/how work on changeset formats and
functionality proceed? I think that's an interesting question.
I'm pretty sure the CollabNet team can't justify spending time
on that feature pre 1.0.
[....]
I'd be reluctant to ship 1.0 with a non-designed patch format,
since it will be hard to change it once we call it stable.
From my experience with changesets, I've concluded that good
changesets and the functionality they nicely enable (like distribution
and fancier merging) _are_ going to have a user-visible and
usage-pattern impact on svn.
I don't mean this as FUD, but I predict that serious sites and
projects that deploy your 1.0 target are likely going to wind up
making some medium-sized changes down the road -- from the practices
they adopt with 1.0 to the practices they'll use when you have
distribution, changeset mgt, and so forth. So there's "stable" in
the sense of "This does what we say it does well enough to rely on"
(that's your 1.0 target, as I see it) and there's stable in the sense
of "The way you use 1.0 is the way you'll use revctl for a long time
to come -- the UI is stable and final" (and I don't think you should
claim that for 1.0 -- I think you should claim "we'll make a best
effort to modify it gracefully".).
The reason that's _not_ FUD is because I don't think that, in the
larger context, anyone with a serious site or project could possibly
be honestly surprised by that at this point -- so they've probably
already figured it into their plans already.
Here's a straw-man proposal to nobody in particular:
Arch and svn have a common interest in developing a nice changeset
format. Such a format should, perhaps, be realized as both some
formal specifications, and a reasonably portable implementation in the
form of a C library.
For arch, at least, I believe it's a good idea that the spec and
implementation not be tied to just one, or for that matter to _any_
revision control system. I would suspect that such goals are also
attractive from the svn perspective.
So I vaguely propose that in exchange for "suitable" support
(whatever that means), I go off and work on that changeset format for a
while. I'll do this work publicly, on arch-users, where svn folks
can participate to whatever degree they like.
I won't do this work in the context of arch itself -- not
immediately. I'll make some maintenance releases of arch, but not
try to integrate this work immediately.
Instead, the outcome of this work will be the candidate standard and
reference implementation -- and that will be ready probably sometime
shortly after svn 1.0 -- and then we can look into revising it with
the full attention of svn developers.
In _that_ context, in the context of revising a proposed changeset
format standard, there I think we can begin to explore some of the
areas where I think a svn (and arch) design review makes sense and
what it might lead to.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 7 00:05:44 2003