Julian Foad <julianfoad@btopenworld.com> writes:
> In the FS-merge case, we can't say "This is clearly a conflict".
> Because we can't know the user's intent, all we can say is, "Sometimes
> this double-delete represents a semantic conflict. We need to
> guarantee that this merge operation is always safe, so we must always
> disallow double-deletes."
Exactly. The original framers of the filesystem logic (myself
included) believed the intent was "make this thing gone". But
whatever, not a sticking point.
> > Fair enough. FWIW, I'm porting r13222 to BDB right now.
>
> That may well be the right thing to do, but I think this behaviour
> ought to be documented in our design documentation. If it is, could
> you update it, and if it isn't, would one of you be prepared to
> write it?
Have you a specific document you'd like updated? The only place where
the more complex merge algorithm is documented (that I know of) is the
libsvn_fs_base 'structure' document.
If it makes you feel any better, I think the change in behavior is
only noticed when driving our APIs in ways that none of our RA layers
drive them on in a small race condition -- basically, when building
transactions off of something other than HEAD. If you and I delete
the same file and commit, there is very little chance of ill side
effect. To trigger the conflict, we'd have to both begin commit txns
and both delete the same file before either of us committed our txn.
By the way, we still get empty revisions today, so I think Eric is
mistaken to assume that r13222 alleviates that. The RA layer is kind
enough to allow double-deletes even if the filesystem now isn't. :-)
#!/bin/sh
rm -rf repos wc
svnadmin create --fs-type bdb repos
svn mkdir -m "" file://`pwd`/repos/A \
file://`pwd`/repos/A/B \
file://`pwd`/repos/A/B/C
svn rm -m "delete 1" file://`pwd`/repos/A/B/C
svn co file://`pwd`/repos/A/B wc -r 1
svn rm wc/C
svn ci -m "delete 2" wc
svn log -v file://`pwd`/repos
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 3 19:32:00 2005