C. Michael Pilato wrote:
> Eric Gillespie <epg@pretzelnet.org> writes:
>
>>"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.
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
Received on Wed Aug 3 19:03:45 2005