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 i
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 ca
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 n
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
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 lo
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
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;
S
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
