> On Feb 25, 2022, at 1:26 PM, Daniel Shahaf <d...@daniel.shahaf.name> wrote:
>
> Mark Phippard wrote on Fri, 25 Feb 2022 17:59 +00:00:
>>> On Fri, Feb 25, 2022 at 12:29 PM Daniel Shahaf <d...@daniel.shahaf.name>
>>> wrote:
>>>
>>> Mark Phippard wrote on Fri, Feb 25, 2022 at 10:39:13 -0500:
>>>> On Fri, Feb 25, 2022 at 10:19 AM Daniel Shahaf <d...@daniel.shahaf.name>
>>>> wrote:
>>>>>
>>>>> Nathan Hartman wrote on Thu, 24 Feb 2022 23:44 +00:00:
>>>>>> On Thu, Feb 24, 2022 at 2:33 PM Mark Phippard <markp...@gmail.com> wrote:
>>>>>>>
>>>>>>> On Thu, Feb 24, 2022 at 10:51 AM Lorenz <loren...@yahoo.com> wrote:
>>>>>>>
>>>>>>>> just discovered, that merging into a RO file succeeds.
>>>>>>>> I my case the file is RO because of a needs-lock property.
>>>>>>>> So when I try to commit I can't.
>>>>>>>>
>>>>>>>> This effect ist at least annoying.
>>>>>>>> There is a reason why the file is read only.
>>>>>>>
>>>>>>> It is interesting both that it was able to do this and also that this
>>>>>>> has never come up before. I am not sure I can wrap my head around what
>>>>>>> I think should even happen here. There is no way you could be expected
>>>>>>> to obtain locks on these files before merging.
>>>>>
>>>>> Why can't we expect that?
>>>>
>>>> I had not considered your proposal to just lock everything before the
>>>> merge. I agree that would be a solution. I cannot predict user
>>>> reaction because it is hard to know what kind of scale we are talking
>>>> about.
>>>
>>> To be clear, I didn't intend that as a "solution"; only as a "first
>>> approximation workaround", as I said there.
>>>
>>>> When I said we could "not expect" what I was getting at is that it
>>>> would require the user to figure out what files the merge was going to
>>>> modify BEFORE they do the merge and lock those files. That does not
>>>> seem reasonable ... again I did not consider the simpler lock
>>>> everything idea.
>>>
>>> Why wouldn't that be reasonable?
>>
>> Different people have different tolerance levels. For me, this would
>> be too much to ask and I would question what the tool is really even
>> doing for me and look for alternatives.
>
> Ah, I see. Yes, requiring the user to _manually_ lock all files changed
> in the branch doesn't sound right. It might work better as something
> libsvn_client/merge.c does by itself. (Although, as discussed in the
> remainder of the thread, the library should only lock files if the merge
> is intended to be committed, and shouldn't lock more files than it needs
> to, if possible.)
>
Your conflict idea sounded like a pretty good solution to me if it can be
implemented. Much better that anything I would have thought possible. It seems
viable if someone were able to do the work and a reasonable user experience
given all of the factors in play here.
Mark
