You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2005/08/02 21:40:08 UTC
FSFS failing regression tests?
Yesterday morning, I abstracted a whole bunch of tests[1] from
tests/libsvn_fs_base/fs-test.c into a new tests/libsvn_fs/fs-test.c so
that FSFS and BDB could both have regression/unit tests. In doing so,
I noticed that FSFS fails two of those tests, but committed my
abstraction anyway because we *want* to see failures like that.
Anyway, I've not had a chance to take a detailed look to see if the
tests are failing for legitimate reasons or not, but wanted to alert
list-folk in case someone else wants to take a look-see. Here are the
failing tests:
FAIL: lt-fs-test 13: delete nodes tree
FAIL: lt-fs-test 17: merging commit
You should be able to reproduce the failures by simply running
"tests/libsvn_fs/fs-test --fs-type=fsfs" (though, of course, the
fs-type option isn't strictly necessary as FSFS is the default now).
-- C-Mike
[1] Some of the tests couldn't be abstracted easily because they used
private APIs, trail_t's, etc. Those remain as BDB-only tests.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FSFS failing regression tests?
Posted by Julian Foad <ju...@btopenworld.com>.
C. Michael Pilato wrote:
> Julian Foad <ju...@btopenworld.com> writes:
>
>>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.
I'm unfamiliar with this layer of Subversion and don't know of any particular
documentation. The document that you mention would presumably fine: better to
have it mentioned somewhere than nowhere. At least, then, when people later
question the decision, we can point to that and say "Look, it's explained there."
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FSFS failing regression tests?
Posted by "C. Michael Pilato" <cm...@collab.net>.
Julian Foad <ju...@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
Re: FSFS failing regression tests?
Posted by Julian Foad <ju...@btopenworld.com>.
C. Michael Pilato wrote:
> Eric Gillespie <ep...@pretzelnet.org> writes:
>
>>"C. Michael Pilato" <cm...@collab.net> writes:
>>
>>>so we're not strictly breaking contract. Just means svn_fs_merge()
>>>isn't nearly as useful as it could be.
>>
>>I disagree. Long ago, and for unrelated reasons, I asked if we
>>could change this behavior. To me, a double delete is clearly a
>>conflict. You can't delete what ain't.
Heh! Let me try to give a wider view of this topic.
Just like in issue #2220 - "svn propdel" returns success on deleting a
non-existent property - the correct choice of behaviour is not obvious. The
question is whether the intent of the "delete" was to remove something or to
cause that thing to be absent. In the former case, the double delete is a
semantic conflict and so should be disallowed; in the latter, it is
semantically not a conflict and so should result in a successful merge.
I don't care whether "svn propdel" behaves one way or the other. However,
there is a third case of the same dilemma in our textual line-based merges
during "svn update". We already accept that such a merge is inherently unsafe,
but we know that it _usually_ gives the desired result and the user will have
the opportunity to check the result. Therefore as part of that merge I believe
we allow and ignore a local change that duplicates the repository change,
whether it be delete, modify or add.
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."
>> Furthermore, it has cost
>>me real time in trying to explain to poor lusers why there are
>>empty revisions with their name on them in our repositories.
>>
>>For whatever reason, it's rather popular around here to delete a
>>file one of your co-workers has already deleted it. The result
>>is an empty revision.
It is a separate issue that an empty revision is generated and is annoying.
You're glossing over some important details. The result is only an empty
revision when there are no changes other than duplicate deletes (obviously) AND
because we don't take steps to prevent creating an empty revision in that
instance. We could take such steps. I'm not saying we should.
> 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?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FSFS failing regression tests?
Posted by "C. Michael Pilato" <cm...@collab.net>.
Eric Gillespie <ep...@pretzelnet.org> writes:
> "C. Michael Pilato" <cm...@collab.net> writes:
>
> > so we're not strictly breaking contract. Just means svn_fs_merge()
> > isn't nearly as useful as it could be.
>
> I disagree. Long ago, and for unrelated reasons, I asked if we
> could change this behavior. To me, a double delete is clearly a
> conflict. You can't delete what ain't. Furthermore, it has cost
> me real time in trying to explain to poor lusers why there are
> empty revisions with their name on them in our repositories.
>
> For whatever reason, it's rather popular around here to delete a
> file one of your co-workers has already deleted it. The result
> is an empty revision.
Fair enough. FWIW, I'm porting r13222 to BDB right now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FSFS failing regression tests?
Posted by David James <ja...@gmail.com>.
On 09 Aug 2005 15:03:33 -0500, C. Michael Pilato <cm...@collab.net> wrote:
> And so, just in case the former is true, I repeat: the disallowing of
> double-deletes by svn_fs_commit_txn() only happens when some other
> user slips in a delete of something I wanted to delete *between the
> time I start my commit transaction and the time the pre-commit
> auto-merge code is run*.
Oops. Thanks for clarifying.
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FSFS failing regression tests?
Posted by "C. Michael Pilato" <cm...@collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> Yup. That's why I believe that the FSFS implementation of the merge is
> wrong. Granted that log messages could be made to "lie", I don't
> believe svn_fs_merge correctness should be subservient to possible log
> message inconsistencies.
Fair enough. So, future discussion may be had (preferably in a new
thread) about your opinion there. (And note that as of this writing,
both FSFS and BDB have identical behavior in this respect.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FSFS failing regression tests?
Posted by Branko Čibej <br...@xbc.nu>.
C. Michael Pilato wrote:
>David James <ja...@gmail.com> writes:
>
>
>
>>On 8/4/05, Michael Brouwer <mi...@tlaloc.net> wrote:
>>
>>
>>>If the user enters a log message stating
>>>
>>>* foo deleted
>>>* bar modified
>>>
>>>And someone else has already deleted foo, allowing this transaction
>>>to go through will result in an incorrect log message since someone
>>>else already deleted foo. I'd say that that warrants giving the user
>>>an out of date error and letting him/her fix the log message before
>>>committing.
>>>
>>>
>>Good argument! I'm convinced.
>>
>>Shall we fix the test to reflect the new behaviour? fs-test looks like
>>it's still failing
>>
>>
>
>fs-test is failing for different reasons altogether, entirely
>unrelated to merges of double-deletes.
>
>Further, despite attempts to make corrections to folks along the way,
>I'm 100% convinced that either:
>
> - most of the participants in this discussion have absolutely no
> idea what is and isn't actually going on, when this double-delete
> consideration does and doesn't actually come into play, and so
> on, or
>
> - folks are just talking about some future behavior of Subversion
> which was not the original intent of this thread.
>
>And so, just in case the former is true, I repeat: the disallowing of
>double-deletes by svn_fs_commit_txn() only happens when some other
>user slips in a delete of something I wanted to delete *between the
>time I start my commit transaction and the time the pre-commit
>auto-merge code is run*.
>
>
Yup. That's why I believe that the FSFS implementation of the merge is
wrong. Granted that log messages could be made to "lie", I don't believe
svn_fs_merge correctness should be subservient to possible log message
inconsistencies.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FSFS failing regression tests?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2005-08-09 at 15:03 -0500, C. Michael Pilato wrote:
> And so, just in case the former is true, I repeat: the disallowing of
> double-deletes by svn_fs_commit_txn() only happens when some other
> user slips in a delete of something I wanted to delete *between the
> time I start my commit transaction and the time the pre-commit
> auto-merge code is run*.
I have no strong opinions about how we handle double deletes, but I
certainly agree that we should be consistent between the two cases:
* I check out r1, perform a delete, and check it in against r2 which
already has that delete.
* I check out r1, perform a delete, and check it in against r1; while
I'm transmitting the commit data, someone slides in a commit which also
performs the delete.
These should have the same behavior, and they don't now, and that's a
bug. Whether we modify the first case or the second case, I don't have
a preference.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FSFS failing regression tests?
Posted by "C. Michael Pilato" <cm...@collab.net>.
David James <ja...@gmail.com> writes:
> On 8/4/05, Michael Brouwer <mi...@tlaloc.net> wrote:
> > If the user enters a log message stating
> >
> > * foo deleted
> > * bar modified
> >
> > And someone else has already deleted foo, allowing this transaction
> > to go through will result in an incorrect log message since someone
> > else already deleted foo. I'd say that that warrants giving the user
> > an out of date error and letting him/her fix the log message before
> > committing.
>
> Good argument! I'm convinced.
>
> Shall we fix the test to reflect the new behaviour? fs-test looks like
> it's still failing
fs-test is failing for different reasons altogether, entirely
unrelated to merges of double-deletes.
Further, despite attempts to make corrections to folks along the way,
I'm 100% convinced that either:
- most of the participants in this discussion have absolutely no
idea what is and isn't actually going on, when this double-delete
consideration does and doesn't actually come into play, and so
on, or
- folks are just talking about some future behavior of Subversion
which was not the original intent of this thread.
And so, just in case the former is true, I repeat: the disallowing of
double-deletes by svn_fs_commit_txn() only happens when some other
user slips in a delete of something I wanted to delete *between the
time I start my commit transaction and the time the pre-commit
auto-merge code is run*.
$ rm -rf repos/
$ svnadmin create repos
$ svn co file://`pwd`/repos wc1
Checked out revision 0.
$ svn co file://`pwd`/repos wc2
Checked out revision 0.
$ touch wc1/foo
$ svn add wc1/foo
A wc1/foo
$ svn ci -m "add foo" wc1
Adding wc1/foo
Transmitting file data .
Committed revision 1.
$ svn up wc2
A wc2/foo
Updated to revision 1.
$ svn rm wc1/foo
D wc1/foo
$ svn rm wc2/foo
D wc2/foo
$ svn ci -m "remove foo" wc1
Deleting wc1/foo
Committed revision 2.
$ svn ci -m "remove foo" wc2
Deleting wc2/foo
Committed revision 3.
$ svn log -v file://`pwd`/repos
------------------------------------------------------------------------
r3 | cmpilato | 2005-08-09 14:57:03 -0500 (Tue, 09 Aug 2005) | 1 line
Changed paths:
remove foo
------------------------------------------------------------------------
r2 | cmpilato | 2005-08-09 14:57:01 -0500 (Tue, 09 Aug 2005) | 1 line
Changed paths:
D /foo
remove foo
------------------------------------------------------------------------
r1 | cmpilato | 2005-08-09 14:56:48 -0500 (Tue, 09 Aug 2005) | 1 line
Changed paths:
A /foo
add foo
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FSFS failing regression tests?
Posted by David James <ja...@gmail.com>.
On 8/4/05, Michael Brouwer <mi...@tlaloc.net> wrote:
> If the user enters a log message stating
>
> * foo deleted
> * bar modified
>
> And someone else has already deleted foo, allowing this transaction
> to go through will result in an incorrect log message since someone
> else already deleted foo. I'd say that that warrants giving the user
> an out of date error and letting him/her fix the log message before
> committing.
Good argument! I'm convinced.
Shall we fix the test to reflect the new behaviour? fs-test looks like
it's still failing
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FSFS failing regression tests?
Posted by Michael Brouwer <mi...@tlaloc.net>.
If the user enters a log message stating
* foo deleted
* bar modified
And someone else has already deleted foo, allowing this transaction
to go through will result in an incorrect log message since someone
else already deleted foo. I'd say that that warrants giving the user
an out of date error and letting him/her fix the log message before
committing.
Michael
On Aug 3, 2005, at 11:50 PM, Branko Čibej wrote:
> Eric Gillespie wrote:
>
>
>> "C. Michael Pilato" <cm...@collab.net> writes:
>>
>>
>>> so we're not strictly breaking contract. Just means svn_fs_merge()
>>> isn't nearly as useful as it could be.
>>>
>>>
>>
>> I disagree. Long ago, and for unrelated reasons, I asked if we
>> could change this behavior. To me, a double delete is clearly a
>> conflict. You can't delete what ain't.
>>
>>
> I don't find this argument convincing. Nobody is deleteing what's
> not there; when tweaking a txn, you can delete what existed in the
> base revision of the transaction, even if BASE is at that instant
> no longer HEAD. The svn_fs_merge algorithm should allow this kind
> of double delete.
>
> What _should_ be forbidden is attempting to delete "foo" if "foo"
> doesn't exist in the txn's BASE; but that can be detected before
> svn_fs_merge is ever called.
>
> I think FSFS's behaviour is incorrect here.
>
>
>> Furthermore, it has cost
>> me real time in trying to explain to poor lusers why there are
>> empty revisions with their name on them in our repositories.
>>
>>
> This is a completely different issue. We can always make sure that
> empty revisions are never committed, and do that gracefully without
> inconveniencing the client with an out-of-date error.
>
> -- Brane
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FSFS failing regression tests?
Posted by Branko Čibej <br...@xbc.nu>.
Eric Gillespie wrote:
>"C. Michael Pilato" <cm...@collab.net> writes:
>
>
>>so we're not strictly breaking contract. Just means svn_fs_merge()
>>isn't nearly as useful as it could be.
>>
>>
>
>I disagree. Long ago, and for unrelated reasons, I asked if we
>could change this behavior. To me, a double delete is clearly a
>conflict. You can't delete what ain't.
>
I don't find this argument convincing. Nobody is deleteing what's not
there; when tweaking a txn, you can delete what existed in the base
revision of the transaction, even if BASE is at that instant no longer
HEAD. The svn_fs_merge algorithm should allow this kind of double delete.
What _should_ be forbidden is attempting to delete "foo" if "foo"
doesn't exist in the txn's BASE; but that can be detected before
svn_fs_merge is ever called.
I think FSFS's behaviour is incorrect here.
>Furthermore, it has cost
>me real time in trying to explain to poor lusers why there are
>empty revisions with their name on them in our repositories.
>
>
This is a completely different issue. We can always make sure that empty
revisions are never committed, and do that gracefully without
inconveniencing the client with an out-of-date error.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FSFS failing regression tests?
Posted by Eric Gillespie <ep...@pretzelnet.org>.
"C. Michael Pilato" <cm...@collab.net> writes:
> so we're not strictly breaking contract. Just means svn_fs_merge()
> isn't nearly as useful as it could be.
I disagree. Long ago, and for unrelated reasons, I asked if we
could change this behavior. To me, a double delete is clearly a
conflict. You can't delete what ain't. Furthermore, it has cost
me real time in trying to explain to poor lusers why there are
empty revisions with their name on them in our repositories.
For whatever reason, it's rather popular around here to delete a
file one of your co-workers has already deleted it. The result
is an empty revision.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FSFS failing regression tests?
Posted by "C. Michael Pilato" <cm...@collab.net>.
Eric Gillespie <ep...@pretzelnet.org> writes:
> "C. Michael Pilato" <cm...@collab.net> writes:
>
> > > FAIL: lt-fs-test 17: merging commit
> >
> > And this one appears to be some sort of strange philosophical
> > disconnect between FSFS and BDB. The situation is the merge() case "E
> > exists neither in SOURCE nor in TARGET". In the BDB code, this
> > so-called "double delete" is allowed -- the code simply doesn't credit
> > the second deleter with the deletion. The FSFS code, however, flags a
> > conflict.
>
> We intentionally changed this in r13222. This change was meant
> to be back-ported to bdb, but I don't think anyone has been
> interested enough to do it.
Ah, so this is the first visible fallout (that I can recall) of the
merge algorithm rewrite -- svn_fs_merge() lost the ability to merge an
obviously reconcilable situation. As you state, there's no promise in
the API that says what kinds of auto-merging will and won't be done,
so we're not strictly breaking contract. Just means svn_fs_merge()
isn't nearly as useful as it could be.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FSFS failing regression tests?
Posted by David James <ja...@gmail.com>.
On 8/3/05, Eric Gillespie <ep...@pretzelnet.org> wrote:
> "C. Michael Pilato" <cm...@collab.net> writes:
>
> > > FAIL: lt-fs-test 17: merging commit
> >
> > And this one appears to be some sort of strange philosophical
> > disconnect between FSFS and BDB. The situation is the merge() case "E
> > exists neither in SOURCE nor in TARGET". In the BDB code, this
> > so-called "double delete" is allowed -- the code simply doesn't credit
> > the second deleter with the deletion. The FSFS code, however, flags a
> > conflict.
>
> We intentionally changed this in r13222. This change was meant
> to be back-ported to bdb, but I don't think anyone has been
> interested enough to do it.
Why would you want to see conflicts in this case? If two people delete
the same file, it seems reasonable to ignore the second delete in a
merge.
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FSFS failing regression tests?
Posted by Eric Gillespie <ep...@pretzelnet.org>.
"C. Michael Pilato" <cm...@collab.net> writes:
> > FAIL: lt-fs-test 17: merging commit
>
> And this one appears to be some sort of strange philosophical
> disconnect between FSFS and BDB. The situation is the merge() case "E
> exists neither in SOURCE nor in TARGET". In the BDB code, this
> so-called "double delete" is allowed -- the code simply doesn't credit
> the second deleter with the deletion. The FSFS code, however, flags a
> conflict.
We intentionally changed this in r13222. This change was meant
to be back-ported to bdb, but I don't think anyone has been
interested enough to do it.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FSFS failing regression tests?
Posted by "C. Michael Pilato" <cm...@collab.net>.
"C. Michael Pilato" <cm...@collab.net> writes:
> Yesterday morning, I abstracted a whole bunch of tests[1] from
> tests/libsvn_fs_base/fs-test.c into a new tests/libsvn_fs/fs-test.c so
> that FSFS and BDB could both have regression/unit tests. In doing so,
> I noticed that FSFS fails two of those tests, but committed my
> abstraction anyway because we *want* to see failures like that.
>
> Anyway, I've not had a chance to take a detailed look to see if the
> tests are failing for legitimate reasons or not, but wanted to alert
> list-folk in case someone else wants to take a look-see. Here are the
> failing tests:
So I finally got a chance to take a somewhat detailed look at the
problems.
> FAIL: lt-fs-test 13: delete nodes tree
Okay, the problem here is with node revision caching. A stale node
revision's dirents list is being read. So FSFS thinks some node
revision ought to exist, but it doesn't. FSFS throws a "dangling id"
error message: "Reference to non-existent node '_0.0.t0-1'
in filesystem 'test-repo-del-tree'".
(This same cache caused me so many problems in the BDB code that I
finally removed it altogether.)
> FAIL: lt-fs-test 17: merging commit
And this one appears to be some sort of strange philosophical
disconnect between FSFS and BDB. The situation is the merge() case "E
exists neither in SOURCE nor in TARGET". In the BDB code, this
so-called "double delete" is allowed -- the code simply doesn't credit
the second deleter with the deletion. The FSFS code, however, flags a
conflict.
Thoughts from folks actually familiar with FSFS internals?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org