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" <cmpilato@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
Received on Thu Aug 4 17:39:06 2005