Peter N. Lundblad wrote:
> The current locking spec says that svn commit unlocks locked files that
> are committed by default. I think this is a good default to prevent people
> from forgetting to unlock, but it seems there was no consensus, so it
> might be time for some discussion.
>
> If we have this default, there will be a --keep-lock(s|ed)? option to let
> people keep their locks. As I said, this is good. Having people often
> forget to unlock could develop a habit of stealing locks as a "normal" way
> of working. Somebody might argue that this is mxing up commands.
I think I agree with you, but it rather depends on whether the "make one
change" way of working is considerably more common than making a series of
commits while keeping the files locked.
> IN any case there is the question if only the committables (the files that
> were actually changed) or all files specified by the targets (and possibly
> recursively) should be unlocked. I think the latter is the best. If you
> commit a subtree with some locked files, a lock shouldn't be left just
> becvause the file wasn't modified.
I find this a compelling argument for considering locked-but-unmodified files
to be part of the commit. I can see this being a common use case.
In particular, I think it would be silly for a 'commit' command with explicit
targets to unlock those targets that were modified but not those that were not.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 15 00:35:20 2004