Hi, Reading up on SVN-2507 it seems very clear that consensus was that the stale locks after deleting a file with --no-unlock is considered a bug. I haven't checked all use cases but it seems to be some nasty unintuitive problems.
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. 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). Would that work for you? Step 3 above would still fail with a tree conflict, but it should be quite trivial to fix: 1. `svn update`. 2. Mark the conflict as resolved. 3. Rename the file you just tried to add. The renamed file will contain your changes. 4. Now you will see a "missing" file in the working copy. Do `svn revert` on that file, to restore your colleague's changes. 5. Do `svn add` and `svn commit` on the renamed file from step 3. (I also tried the above steps with TortoiseSVN and it was fairly straight forward. Maybe it could even offer to rename the local file as a step in the conflict resolution process, I'll look into that at some point). Kind regards, Daniel Den tis 3 juni 2025 kl 09:06 skrev Ondra Medek <xmed...@gmail.com>: > Thanks for replies to all. > > Just to the sentence: > > > Subversion ... can only detect conflicts, not resolve them ... > > IMO Subversion locks (or locks in general) are a collaboration tool to > prevent conflicts (without other communication channels). It works > well with files in the repository. It seems to me unfortunate that it > does not work for the new (or deleted) files, too. > > Furthemore, from bug https://issues.apache.org/jira/browse/SVN-2507 it > seems to me it's technically possible to have a lock for a file not in > the repository - it's possible to remove a locked file with "svn > commit --no-unlock". Then, only the user holding the lock may create > and commit a new file of the same name. (And that's what I need :)) > So, what about to take this as an advantage, and allow svn lock and > svn unlock to work with files not in the repository? (It would solve > SVN-2507, too). > > Cheers > Andy > > On Tue, 3 Jun 2025 at 00:12, Branko Čibej <br...@apache.org> wrote: > > > > You can only lock files that are in the repository. A new file in the > working copy, even after being "svn add"-ed, can't be locked until it's > committed. > > > > Daniel is correct, tree conflicts are the only mechanism that can > reliably detect the issue. Resolving it requires users to talk to each > other; Subversion is not a communication channel, it's a collaboration > tool, it can only detect conflicts, not resolve them (in general, that is; > conflicts in text files are an exception, and even there, no automated > merge is error-free). > > > > -- Brane > > > > On Mon, 2 Jun 2025, 17:54 Daniel Sahlberg, <daniel.l.sahlb...@gmail.com> > wrote: > >> > >> Hi > >> I think the answer on Stack Overflow is spot on, there is no way to > avoid this problem. As already explained there, the tree conflict is > probably the easiest solution anyway compared to a ”central naming > authority” or other manual workaround. > >> Kind regards > >> Daniel > >> > >> mån 2 juni 2025 kl. 17:22 skrev Ondra Medek <xmed...@gmail.com>: > >>> > >>> Hello, > >>> > >>> We have a directory versioned in SVN and use svn lock to prevent > >>> conflicts (of non-mergeable files). However, when I create a new file > >>> and do svn lock newfile, then got error: > >>> > >>> svn: E155010: The node '...\newfile' was not found. > >>> > >>> When 2 users create and commit `newfile` at the same time, then one of > >>> them has a tree conflict. > >>> How to use svn lock for a new file? Or is there any other way to > >>> prevent conflicts when 2 users create the same file and the same time? > >>> See my SO question > >>> > https://stackoverflow.com/questions/79639066/how-to-lock-or-prevent-conflicts-for-a-new-file-with-svn/79640745 > >>> and workaround > https://stackoverflow.com/questions/79639066/how-to-lock-or-prevent-conflicts-for-a-new-file-with-svn/79640745 > >>> > >>> If this functionality is missing, then consider it as a feature > >>> request. But then, the bug > >>> https://issues.apache.org/jira/browse/SVN-2507 may be a blocker of > >>> such feature request. > >>> > >>> Thanks > >>> Andy >
