--- Andy Levy <andy.levy_at_gmail.com> wrote:
> > > <jd_hardcastle_at_yahoo.cm> wrote:
> > > > > Hello Chaps!
> > > > >
> > > > >
> > > > > I hope I am in the right place!
> > > > >
> > > > > I'd like to engineer it so that i can have
> > > READONLY
> > > > > access to an area, and yet. Still be able
> to
> > > lock
> > > > > files in it?
> > > > >
> > > > > I have tried this..
> > > > >
> > > > > <LimitExcept GET PROPFIND OPTIONS
> > > REPORT
> > > > > LOCK>
> > > > > Require valid-user
> > > > > </LimitExcept>
> > > > >
> > > > >
> > > > > but it doesn't seem to work. Any help or
> clues?
> > >
> > > A) This is a Subversion server question, not
> TSVN.
> > > B) What's your use case? Locking is only
> required if
> > > a user is going
> > > to modify and commit changes. If they're
> locking a
> > > file, but not
> > > allowed to make any changes, what's the point
> of
> > > locking (beyond
> > > annoying those who *can* make changes)?
> > >
> >
> > a) Sorry :-/
> > b) The use case is if our branches contain
> mergeable
> > and non-mergeable files. All users must work on
> > branches, only sysadmin can commit to trunk - to
> keep
> > it at a minimum level of 'excellence'. So because
> of
> > this, if a user wants to 'work' on a binary file
> in
> > their branch. It would be great if they could
> lock it
> > in the main - as a signal to others and then work
> on
> > it in their branch..
> >
> > hope that makes sense?
>
> Not really. The whole point of having developer
> branches is so that
> one developer can work on a file without being
> disturbed by another.
>
> And if the other developers never think to check
> trunk for a lock,
> they'll never know.
>
> It sounds like you have a team communication
> problem, which is not
> solvable via software.
>
It is an overhang of a repository layout that
pre-dates branches (vss) we have moved as much as we
can but we can't move it all. As we'd like to keep the
trunk clean from unauthorised commits we'd like users
to be be able to lock files that are duplicated in
branches as a way to 'signal' their intent to modify a
non-mergeable file. If they forget to do it, yes you
are right we still have a problem. But if they don't
follow the process then that is their bad.. not mine.
It would be hard to communicate at this level as we
are about 100 people working on different bits at
different sites emailing everyone on a lock or
whatever would be onerous...
I know this is a known issue, locking of files
traversing branches.. I am trying to side-step the
wider issue with a little human interaction - but not
too much!
-----------------------
N: Jon Hardcastle
E: Jon_at_eHardcastle.com
'The writing is on the wall...'
-----------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-03-26 10:27:05 CET