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

Re: Need To "Lock" Many Files Within Multiple Folders

From: Andy Levy <andy.levy_at_gmail.com>
Date: 2006-12-11 17:24:30 CET

On 12/7/06, Marvin Toll <tollm@dteenergy.com> wrote:
> * Objective Statement *
> We have folders of (.class / .xml / .txt etc. etc.) artifacts matured over
> many days. Once they are certified for promotion to our Integration
> environment, we would like to prohibit any further changes to the artifacts.
> Thus we can be assured they are viewable, but not alterable, before future
> promotions to our Quality Assurance and (later) Production environments.
> * Initial Thinking *
> We anticipated using the two locking mechanisms within Subversion to meet
> the objective:
> svn propset svn:needs-lock (for communication)
> svn lock (to lock the artifacts)

Except users can "steal" locks trivially.

> * Scalability *
> Unfortunately, we are finding executing these commands against potentially
> hundreds of artifacts in differing directory combinations and depths to be
> problematic with the lack of recursive capability apparent to us (for both
> commands).
> * Options? *
> Short of copying these files to another project that has "read-only" access;
> Are there some solutions for meeting our objective?

This is usually the solution people use. Create a copy of the project
known as a "tag", then disallow write access to the tags directory
(either via hook script, or by setting permissions so that only
certain users can write to the tags directory - usually a release
management group). Thanks to Subversion's cheap copies, the amount of
space used for this is trivial.

See http://svnbook.red-bean.com/nightly/en/svn.branchmerge.tags.html
for more on tagging.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Dec 11 17:38:36 2006

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

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