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

Re: Commit without lock held

From: Andy Levy <andy.levy_at_gmail.com>
Date: Wed, 28 May 2014 07:13:49 -0400

On Wed, May 28, 2014 at 4:04 AM, Niemann, Hartmut
<hartmut.niemann_at_siemens.com> wrote:
> Hello!
>
>
>
> I want to store files in SVN that are binary and need to be writable by the
> application that uses them,
>
> even when the modifications are not meant to be committed. (I.e.: the
> application stores some
>
> check-and-build information (most notably a build time-stamp) in the source
> files. Ugly, but that’s the way it is now.)
>
>
>
> Normally, I would set all files to “needs-lock”.
>
> The developer locks the files he/she wants to change,
>
> but needs to set all not-locked files to “writable” as well.
>
>
>
> During the development step all files will change, but only the changes in
> the files manually edited are interesting
>
> and need to be committed.
>
>
>
> But: Even if the developer does not hold a lock, a commit will succeed (TSVN
> 1.8.6) at the moment,
>
> unless a lock is held by someone else.
>
> Is this intentional? Could that be disabled?

This is by design. Locking is meant as a communication mechanism, not
an airtight process control. A file marked with svn:needs-lock should
be read-only in the working copy, which should signal the user to get
a lock, or bypass Subversion and manually change the read-only
attribute of the file (at which point, the user should be realizing
that they're doing something out of the ordinary.

> In my use case “Needs-lock” should mean “needs a deliberate locking step”,
> not only “needs that the file is not locked by someone else”.
>
> Can this be done?

Only via a pre-commit hook script on the server which checks the
incoming transaction & disallows the commit if there are any
lock-required files which aren't locked by the committing user.

However, I would suggest that if your process is such that you're
requiring a lock be held by the committing user even if no other user
has a lock at that time, you need to re-examine your tools or
processes as this is irregular and outside what one would consider
"normal" for locking scenarios.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3079364

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2014-05-28 13:14:34 CEST

This is an archived mail posted to the TortoiseSVN Users mailing list.