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
