Greg Stein <gstein@lyra.org> writes:
> > Why reinvent the wheel? When you call svn_fs_commit_txn, it will
> > automatically decide if the user is out-of-date. You don't need to do
> > this check yourself as you build a txn against 'youngest'.
>
> Why wait for commit_txn? That occurs *after* all the data has been delivered
> to the server. On my poor little 56k modem, that could be 15 minutes later.
> Then, *one* file is out of date, I say "fuck!", update that one file, and
> recommit the whole bloody thing.
Ah, yes, sure. But note an earlier mail thread: ra_local is planning
to do early conflict detection. Every time it receives a change, it
will call fs_merge() and potentially reject the whole commit -- all
before the text deltas are sent. (That's why our commit-driver is
sending postfix textdeltas, after all.)
So we agree here; we just use differing methods to check for
conflicts as we go. You use DAV-ey methods, I use fs_merge().
> > Just build a txn based on whatever revision the client passes to your
> > replace_root() function. When you get a replace_dir(rev) and rev !=
> > the parent's rev, then call svn_fs_copy. That's what ra_local does.
>
> replace_root? What's that?
>
> mod_dav_svn does not have a replace_root call, and the replace_root on the
> client is not marshalled over the wire. IOW, the base_revision parameter to
> replace_root is dropped on the floor.
No, but libsvn_ra_local has a replace_root call. You *could* send
that revision over the wire, and have mod_dav_svn use it to create a
transaction.
> My question about the transaction roots, and using the latest, also leads to
> the fact that I never need to do an svn_fs_copy. If you want to talk about
> extra work, ra_local is the one doing the work with those copies :-)
Oy, I guess you're right. The only reason I use fs_copy() is so that
fs_merge() can accurately tell me if my transaction conflicts.
(Of course fs_copy isn't really "work"; it's super cheap.)
> Now, let's get back to the original question. Is there a *problem* with
> using the latest revision for the transaction root, rather than an arbitrary
> revision (i.e. the one passed to replace_root).
I don't think that there's a theoretical problem with what you're
doing, as long as your definition of "latest revision" remains fixed
after you create the transaction. ("latest revision" shouldn't be a
moving target).
But what bothers me is that we have two totally different systems for
building transactions here. In my get, this just seems like bad
software design. Let's choose a commit design and stick to it.
On the one hand, I could plea: why on earth have we slaved over
making fs_copy and fs_merge work correctly, if you're not even going
to use them? Why ignore the interfaces svn_fs provides?
On the other hand, I could capitulate: I mean, if you refuse to build
a mixed-revision "mirror" of the working copy, then maybe I should
stop doing it also. Maybe ra_local should switch to your system as
well; maybe it should do manual comparisons of node-rev-ids as it
goes, ignoring the fs's built-in ability to detect conflict copies;
maybe ra_local, too, should ignore the base_revision argument to
replace_root -- so that this editor argument now only has meaning in
one direction; and it wouldn't call fs_copy anymore, since it just
looks at node-rev-ids. I could do all this, but I wouldn't be happy.
The real issue is that I can't stand the thought of a world where we
discover a commit-merge bug, but it only happens in one ra layer and
not the other. We shouldn't have two independent commit systems.
Received on Sat Oct 21 14:36:26 2006