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.) Cheers, Daniel
