[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Locking] commit and unlock

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2004-12-15 00:34:02 CET

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.