Re: transaction roots

On Thu, Mar 29, 2001 at 06:32:15PM -0600, Ben Collins-Sussman wrote:
>...
> Basically, if commits are ever broken, I don't want to end up back in
> the CVS mindeset: "oh, gotta test this bug (or fix) in the local case
> and the network case *separately*."
>
> If there's one *theory* that describes how to do a commit, life gets
> much easier. We fall less often into that maintainability trap.

Generally, I agree here.

But it is also a matter of degree. Commits over the network are *vastly*
different to begin with. Yes, it would be nice to have the endpoints as
similar as possible, but let's not lose sight that we will have whole
separate classes of bugs between the two paths.

Lastly, these two paths are *specifically* why we wanted to avoid ra_local
as much as possible. Just get people to use and stick with ra_dav even when
they work on their own machine.

> So my objection is that we currently have two different commit
> systems; and I'm arguing that if we have to choose one system,
> ra_local's is better... just because it's using fs_copy() and
> fs_merge(). I think I'd rather depend on the (future) robustness of
> these funcs rather than doing manual node-rev-id comparisons.

I don't see the justification that ra_local's system is better (you state it
above, as if it were obvious). If anything, I could say that ra_dav's is
better because I don't need to use fs_copy and fs_merge :-). Less code to
call, so less potential for problems.

ra_local could perform the same algorithm:

*) create the transaction based on latest
*) for each change to REV:PATH, do:
   - open root REV, fetch ID of PATH
   - (open) root TXN, fetch ID of path
   - compare

[ note the base_revision isn't ignored; it is used to determine REV in the
  above steps ]

You would then eliminate copies and merges, and align ra_local (well, the FS
editor) with ra_dav's algorithm.

You asked, "why do that, when copy and merge were written to do it for you?"
fs_copy is definitely needed because "real" copies do happen. I never said
that fs_merge was needed :-) Just because it exists, doesn't mean that I
should use it, or that it should continue to exist. I always saw it as a
step of the commit function, rather than a "first order" function.

[ trying to pull some threads together here ]

Ben wrote in another thread:
>...
> 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().

I use IDs for difference detection. Has nothing to do with DAV. You use ID's
for detection, via the fs_merge call.

>...
> 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).

I don't retarget the transaction. "latest" is the latest revision at the
time the commit started, and remains that way. Of course, if somebody else
creates a revision while the commit is occurring, then svn_fs_commit_txn
will do a merge and potentially throw a conflict at that time (the late
conflict could arise for an item that I previously checked, but became out
of date during the commit process).

> [ long (semi-sarcastic :-) spiel about converting ra_local ]

It isn't as bad as all that. The short clip of an algorithm above is about
all that is needed. Whenever you get a replace_file or replace_dir, you
could just call a "check_latest" function. You know the base_revision (REV)
for the file/dir, and can easily do the comparison.

Note: the check is also quite easy. It is a simple equality check. If the
REV is older than TXN's ("latest" at commit-start), then the user is
obviously out of date. If the REV is *newer*, then the user purposefully
screwed the commit :-). Stopping and restarting the commit is sufficient;
they don't even need to update.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/