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

On 3. 6. 25 17:26, Ondra Medek wrote:
> Remarks to Andreas reply. First, I would like to quote Stefan Küng's
> comment from SVN-2507: "First, remember that locking is often done by
> non-technical people (e.g., designers working on images, non-devs
> working on word docs, ...) so they're happy if they can use svn at
> all."
>
> - So, the point is not to minimize conflicts. Our customers use svn
> with locks to avoid conflicts at all. (And branches and merges as
> well.)
> - Different file naming is not a solution for us, because some file
> names are fixed. E.g. you have a directory "projectA" and you may want
> to add a fixed named file like "summary.xyz". The file may not exist
> (then the result has no summary) or may exist there (then summary is
> added to the result).
>
> Generally, it's not a blocker for us. We will add some workaround for
> this to our app. And our customers using CLI would have to be more
> cautious. I just still think if Subversion would allow locking and
> unlocking for non-existing paths it would improve usability in such
> scenarios.

The proposal is "locking and unlocking of non-existent paths". I suggest 
that you expand on this with a high-level design, including UI/UX 
(command-line is still UI) considerations, and what kind of API changes 
we'd need for, e.g., Tortoisesvn to be able to take advantage of it; 
keeping in mind that:

  * Subversion can only lock files, not directories.
  * Subversion will only allow the lock owner to commit/create the file.
  * What happens if someone renames some part of the parent path of the
    locked nonexistent thing?
  * Similarly, what happens when a locked thing is accessed through a
    (local) svn:external? If it's accessible in the working copy through
    a committed symlink?
  * What happens if someone wants to create a directory with the same
    name? Or move/rename an existing one in place?


So, yeah, all of this is not trivial. Consider that we tried to work out 
locking of directories for literally years, and we couldn't come up with 
a consistent model that didn't have more holes and edge-cases than solid 
features.

I'm not saying it can't be done, I fully encourage contributions to the 
project. I'm just warning here that what seems like a simple new feature 
has a lot of ramifications that need to be considered in advance. Every 
time we did not and made "trivial" decisions, they came back to haunt us 
later.


-- Brane



> On Tue, 3 Jun 2025 at 16:00, Andreas Stieger<[email protected]>  wrote:
>>
>> 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
>>