On Mon, Dec 16, 2002 at 01:29:31PM -0800, Tom Lord wrote:
>...
> An admittedly quick read through the schema document made it seem that
> pending transactions are recorded in the database and that that record
> includes a transaction number -- which implies the txn number is
> assigned early.
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.
>...
> Specifically, it seemed to me that early in
> the transaction, a commit examines the revnum of the repository to
> make sure that the wd is up-to-date wrt that revnum, and refuses to
> proceed if it is not. That too, implies that the client (effectively)
> knows its new revnum early in the txn. (I suppose now, in retrospect,
> that the commit is not looking at the global revnum, but only at the
> last revnum at which files being committed previously changed.)
That parenthetical note is correct: we only want to ensure that they are
changing the latest copy of the file/directory. They must be up-to-date for
each file/dir changed before the txn can be commited and receive a revnum.
There aren't any race conditions in here either. We merge the new changset
against <current-revnum>. Then we acquire a lock on the revnum->txnid
mapping table. Then we merge against <current-revnum> again, if it changed
from the last merge. Then we alloc a new revnum and associate it with the
txnid, then we release the lock.
>...
> 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.
>...
> If I'm reading the FAQ correctly ( :-), revnum is, in essense, an
> implementation detail -- it is "mostly hidden" from users for revision
> control purposes.
Nah. There is a tension that exists. The revnum rate-of-change should not be
a cause for concern, yet the revnum is also a *very* useful tool. The FAQ
tends towards assuaging concern about revnums, but when people actually
start using SVN, they'll understand their utility quite a bit more.
> 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.
>...
> When two related lines are merged or partialy merged, those changesets
> are the ideal "unit of merging". One might ask "on my branch, what's
> been merged in from the foo mainline?" and get:
Part of the issue is that SVN imposes a linear ordering to the changesets
and that arbitrary composition is not easily supported. I think with some
work, people could definitely do change-composition-like stuff.
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 Mon Dec 16 23:45:45 2002