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 guess ideally merge would obtain locks but I just do not know what
>> merge should do if it cannot obtain the lock. I guess it should
>> behave the same way it would if the file was not present due to it
>> being a sparse working copy.
>
> Hopefully there would be a visible warning if that happened!
>
>> Maybe merge should just refuse to run at all if it detects any
>> svn:needs-lock properties in the WC?
>
> Then it would never be able to run; I think you meant: refuse to run
> if we don't hold the lock on a file that has the svn:needs-lock
> property. However, it would be rather irritating if the refusal to run
> were caused by files unaffected by the merge.
Or if the user deliberately did the merge without intending to commit it.
How about making this situation a conflict? "local file not locked,
incoming edit upon merge". Then the file is not silently changed, but
the user can use --accept or «svn resolve» to make the changes anyway if
they know that's what they want.
> Whether that is more or less annoying than merging to the read-only
> file is up to interpretation.
>
>> It is a hard problem to solve.
>
> I suggest to file an issue for now.
>
> Also, perhaps a workaround exists, or at least a way for users to
> check whether they should obtain locks before running a merge,
> preferably one that uses existing SVN commands. Some combination of
> 'svn merge --dry-run' and 'svn status -u', or something along those
> lines?
For a first approximation I'd go for:
svn lock ${all files with svn:needs-lock}
svn merge
svn unlock ${appropriate subset of the files just locked}
Cheers,
Daniel
