Ben Collins-Sussman <sussman@collab.net> writes:
> On Fri, 2003-10-31 at 16:16, Gareth McCaughan wrote:
>
> > How difficult would the following be? (I'm guessing that the
> > answer is "altogether too difficult".) In txn_body_commit,
> > before giving up because a txn is out of date, check to see
> > whether the two revisions are "the same" (i.e., nothing has
> > changed between them). If they aren't, then we report
> > SVN_ERR_FS_TXN_OUT_OF_DATE as at present. But
> > if they're the same, then we allow everything to go ahead.
> >
> > We must be able (in principle) to tell whether anything has
> > changed, because otherwise "svn status" wouldn't work.
> > It naively looks to me as if svn_fs_contents_changed will
> > determine this.
> >
> > Doubtless I'm being *very* naive here. Enlighten me ...
>
> I think I'll let cmpilato field this question... :-)
If I understand the proposal, you're effectively talking about a
content-based merge of sorts, allowing a potential conflict to "slide"
if the result would be effectively a no-op. This would be a royal
pain, not so much because of the calls to
svn_fs_contents_changed()[1], but because of the patch-up to the
'changes' table that would be required -- you can't give credit for a
change to a transaction that didn't actually affect the change.
[1] svn_fs_contents_changed(), by the way, probably won't be
sufficient for the needs here. If we're talking about directory
nodes here, deleting an entry from a directory will tweak its
DATA-KEY, and svn_fs_contents_changed() will bail right there --
it doesn't actually attempt to contextually compare contents.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 1 00:12:59 2003