On Mon, Dec 16, 2002 at 04:17:58PM -0800, Tom Lord wrote:
>...
> > still have either a single thread of execution or a
> > distributed commit protocol through which all commits must
> > pass.
>
> Correct, and we aren't worrying about this right now.
>
> I understand that. Although it's tangential to the main points of my
> comments on the 1.0 plans, I'll point out that I think it is worth
> thinking about right now, and here's why: The FSDB sketch I sent this
> list has applications far beyond revision control, including
> applications where very high txn rates are important. At the same
> time, an implementation of that sketch, sufficient for revision
> control, looks from where I sit like a simplification of what svn
> currently has.
For argument's sake, I'll concede these two points as true.
> So, it's worth considering because you can
> simultaneously simplify svn and prepare for applications where huge
> txn rates are important.
The svn architecture isn't going to radically change for 1.0. I don't think
that any of the developers have any interest in doing that. Therefore, if
you would like to build FSDB, then it will need to be a layer on top of the
svn_fs API (rather than below it).
Nobody has performed extensive commit-time benchmarks for SVN right now,
preferring completion of functionality over fine-tuning of performance. Not
to mention benchmarks lie :-) But let's say for argument's sake that we can
only do 10 commits per second on "typical" hardware. I am *SO* fine with
that for a 1.0 release. "High txn rates" isn't really a goal that
I/CollabNet cares much about. I am pretty darn sure there *are* people here
who are, and I am equally sure that they'll work on the problem. "Great!" I
say. But will 1.0 be held up? Will an architecture redesign occur to ensure
that post-1.0 it can hit those rates? I don't think so.
[ yes, there have been a number of benchmarks run, but they're concentrating
on pretty high-order operations; nothing like what you'd be looking for
out of an FSDB ]
> > Yet within one repository, merge history is expressed wrt. revnum.
> > The emerging plan for distributed revision control seems to be aiming
> > at recording merge history as <guid,revnum> pairs.
>
> Whatever. Those are merely ideas, and they won't become concrete
> for quite a while. I think it is entirely possible to record the
> data as <guid,txnid> pairs. Revnum doesn't have to appear.
>
> [As an aside: did you really mean txnid, not revnum?]
I certainly did. If you use <guid,txnid>, then you would be out of the
conflicting-revnum business. In the current SVN FS data model, the txnid is
the important identifier. The revnum is simply turned into a txnid before
any real work is done. If revnums scare you :-), then use txnid.
The problem is that txnids are defined as non-integers right now, so they
don't range-compress like revnums do. But txnids *will* become integers at
some point, so we'll get range compression back (altho it will have holes,
but that's okay as I suspect revnums [as they occur in a merge source] have
holes in the ranges, too).
> I think there's now ample evidence that not only doesn't revnum _have_
> to appear in merge history, it _shouldn't_ appear. "So what?" you
> ask, "This is all in the future, anyway."
>
> It's not in the future. It has impacts on UI, on project layout
> within repositories, on repository schema, and on protocols. Even if
> you want to leave the specific feature of merge history out for now,
> it still has impacts on the features you aren't leaving out.
Yup. It has an impact. And we can solve that later. I'm confident it can be
solved, and I'll also grant that the total time expenditure will be higher
if we defer the thinking on that solution. But I'll *definitely* spend
future time on the problem to get a 1.0 sooner.
It's a simple benefit/cost, and I think you're seeing it whenever the SVN
community talks about SVN 1.0. We get the benefit of a "final" release
sooner, at the cost of more dev work later to compensate for "incorrect"
choices made now.
> Moreover, there's no good reason to leave it in the future. It's
> basically been solved in prototype form, and it's only a tactical
> effort to figure out how to interpret that prototype in a svn context.
Great. If it is only tactical, then please begin execution :-). Patches and
working code are welcome...
Look. In all seriousness, I believe you have some great ideas. You also
expres them well, if a bit lengthy. But I think you're also going to have to
step up to the plate and do some coding if you want to see some of these
ideas reduced to practice. *Especially* if you're talking about changing SVN
itself, rather than building on top of it.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 17 03:42:52 2002