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

Commit without lock held

From: Niemann, Hartmut <hartmut.niemann_at_siemens.com>
Date: Wed, 28 May 2014 08:04:33 +0000


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?
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?

Mit freundlichen Grüßen
Dr. Hartmut Niemann

Siemens AG
Infrastructure & Cities Sector
Rail Systems Division
Locomotives and Components
Werner-von-Siemens-Str. 67
91052 Erlangen, Deutschland
Tel: +49 9131 7-34264
Fax: +49 9131 7-26254

Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Klaus Helmrich, Hermann Requardt, Siegfried Russwurm, Ralf P. Thomas; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2014-05-28 10:04:47 CEST

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

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