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. Andy 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 >
