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
