Re: How to lock or prevent conflicts for a new file with SVN

On 2025-06-03 10:59, Daniel Sahlberg wrote:
> I think the best option would be to teach `svn commit` to SET a lock 
> after commit (much like it can be told to not RELEASE the lock on an 
> already committed file). Then your workflow would be:
> 1. Create a new empty file.
> 2. Add it.
> 3. Commit it, with the new --set-lock option.

Except commit works on a PATH which may be a WC, and the committed item 
is not necessarily the exhaustive list of items to be locked. Also this 
still creates a revision which may no be desired.

> 4. Edit the file, adding whatever content you need.
> 5. Commit it (possibly with --no-unlock if you'd like to repeat steps 
> 4 and 5).

This seems to be a marginal improvement, if any.

Let's look at this this way: This operation is a conflict in /any /scm, 
even content-addressable ones with weaker file identities. In svn the 
file identity is a strong one, hence the need for a tree conflict. Are 
we dealing with a case of a feature request to cover difficult UX for 
resolving tree conflicts? Mind you that even if we "fix" this the same 
project will see issues when they start branching and merging.

The initial question was 'how to use locks to prevent tree conflicts. 
The premise was that locks are otherwise used in the project to 
serialize changes for non-mergable content. If we rephrase it then we 
may arrive at something better: How do we have fewer tree conflicts? I 
would point to time or uuid based naming address this for a linear 
development model. Alternatively I would suggest feature branches by 
default, and serializing to the final file name (as copy) when 
reintegrating.

IMHO this belongs higher in the stack.

Andreas