I would not use locking for this; its not really the intent, nor is
it a true "lock" in the sense that locks can be stolen (its really
designed as a co-operative lock).
Why do you need to copy the files to another project? Why not just
change the folders access to read-only?
--Tim
On Dec 7, 2006, at 9:27 AM, Marvin Toll 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)
>
> * 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?
>
>
> _Marvin
>
>
> -----------------------------------------------------
> | DTE Energy - DTE2 Project Team
> | Work: 313.235.8080
> | USA Cell: 248.866.4897 (free incoming)
> | Message: 2488664897@messaging.nextel.com
> | Email: TollM@dteEnergy.com
> -----------------------------------------------------
> ---------------------------------------------------------------------
> 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:48:06 2006