Ok I see changes are not simple and it could be a bigger change, maybe breaking (relaxing) some current lock rules. But mind that even the current implementation has flaws - SVN-2507. So, my approach is to prefer simplicity and usability over holes-free implementation. From my point of view, it's important to have a tool to list all locks and unlock (delete) locks when it comes to issues after renaming / deleting files or directories. I.e. put the burden of such situations you have mentioned to the users, but give them a tool to fix that easily.
Just a few notes: * The problem with renames is already in the current SVN implementation, see SVN-2507 comment https://issues.apache.org/jira/browse/SVN-2507?focusedCommentId=14922961&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14922961 * What happens with the remaining lock after file delete, see SVN-2507, if you create a directory with the same name? Or move/rename an existing one in place? * Git LFS allows you to lock / unlock any path and list all locks. (I am aware Git has different principles working with files and directories.) Cheers Andy On Tue, 3 Jun 2025 at 21:09, Branko Čibej <br...@apache.org> wrote: > > 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 <andreas.stie...@gmx.de> 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 > >
