[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: Frode Tenneboe <frode.tennebo_at_saabgroup.com>
Date: 2006-12-14 18:09:34 CET

On Tue, 2006-12-12 at 15:30 -0500, Marvin Toll wrote:
> Tim Hill suggested using the "Authorization" mechanism rather than the
> "Locking" mechanism to accomplish our objective. After consideration,
> our team has opted to use his suggestion.

Could you please elaborate on this or point me to some gory details?
Has it been listed as an issue? I'd like to review the proposal.

> Although the strategy requires logging onto the repository server and
> hand-editing the applicable file, it benefits the project by
> sustaining read/write access for a targetted group (of Promotion
> Managers) while prohibiting "lock stealing" by developers.

Will this work for an fsfs repository?

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

This is more or less the same situation as I have. I have several
products which, when reaching a desired level of maturity goes into a
higher level product which (sooner or later...) becomes a deliverable.
In one system we have over 100 products which is needed for a complete
deliverable. Once I have tagged it all up (using svn terminology, we
are currently using a different system for this, but hopefully, with
such a feature we can use Subversion for production projects as well) we
(ok, the CM/QA people) need two things:

1) reproduceability, ie. said deliverable can be generated anew some
time into the future (say 5 years), and
2) tamper proof, ie. tagged products can't be tampered with either by
malice or by ignorance.

2) is a pre-requisite for 1) and today 2) fails trivially.

I read something about changing permissions on "the directory" of the
tag, but I see no directory. Is that a function of me using fsfs?

The number of products isn't really that important either. Even if it
was only one, we need to have some degree of certainty that the code
already there for a given tag doesn't change. Ideally I'd like to
"freeze" the trunk as well to discourage "overzealous" commits.

 -Frode

-- 
^ Frode Tennebø             | email: Frode.Tennebo@saabgroup.com ^
| SAAB Microwave Systems AS | Isebakkeveien 49                   |
| N-1788 Halden             | Phone: +47 45 24 99 39             |
| with Standard.Disclaimer; use Standard.Disclaimer;             |
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Dec 14 18:08:27 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.