The txn id *is* assigned early. First thing you do when
building a commit. Only when the txn is actually committed,
though, do you associate a revnum with that txn id.
That's what I missed. I thought the two ids were one-in-the-same.
> less serious way). In particular, if a single repository
> is implemented over a distributed database, all of the
> participating servers must still synchronize for every
> transaction in order to allocate txn numbers -- you'll
> 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. So, it's worth considering because you can
simultaneously simplify svn and prepare for applications where huge
txn rates are important.
> 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 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.
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.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 17 01:06:24 2002