Hi Sussman,
If it is a expected behaviour, this doc should be wrong.
subversion/libsvn_fs_base/notes/structure under 'Merging algorithm' section.
"If SOURCE-ENTRY and TARGET-ENTRY are both null, that's a
double delete; flag a conflict."
Let me which needs a correction Doc/Code.
With regards
Kamesh Jayachandran
Ben Collins-Sussman wrote:
> On 3/17/06, Eric Gillespie <epg@pretzelnet.org> wrote:
>
>> "Ben Collins-Sussman" <sussman@red-bean.com> writes:
>>
>>
>>> I think this is expected. If you look at fs.c:merge(), two deletes of
>>> the same thing are considered mergeable. So you end up creating a new
>>> revision identical to the previous one, with no changed paths.
>>>
>> Heh, yes, it is expected by somene who reads fs.c:merge(), or
>> someone like you with a good memory of it. It isn't expected by
>> anyone else.
>>
>> This happens pretty often, and not one victim i've dealt with
>> understood it. I was quite surprised the first time it was
>> reported to me, too. I said then that i think this is a bug and
>> i still say it now.
>>
>>
>
> Wow, I've never heard of anyone accidentally committing an 'emtpy'
> revision like this. I mean, I know it's *theoretically* possible, but
> in 6 years I've not seen a report about it. Or maybe I just don't
> remember such reports.
>
> I do remember some old list conversations where we decided that
> libsvn_fs would not enforce any sort of rule that 'commits must not be
> empty'. Didn't we agree on that?
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 20 12:02:42 2006