> >> If someone locked the file, they must be thinking that
> your changes,
> >> whatever they are, won't be mergeable.
> >>
> > Rubbish.
> >
> > Say you are generating a release. You want to stop anyone
> else making
> > checkins for a day or so while you are doing that, so
> locking all the
> > files would seem a sensible move.
>
> Interesting use of locks...
>
> We usually cut a branch for that final release process and
> then a tag when we get a release built and sent to QA.
I am perfectly happy to support that particular use of locks. It may be
*different* from the use of branch and tag, but it's certainly not
inferior. In fact, the use of locks plus branch/tag might be used
complementary.
What I'm pushing for does not conflict with that use of locks. The
first change I'm pushing for is to cache the lock information (no
conflict with anything), and the second change I'm pushing for is the
*option* to change the behavior of the client based on that cached
information.
I understand that any change of behavior will be popular with some
people and unpopular with others, so it's crucial to allow the client to
behave in the traditional way, while also supporting the new feature.
There might, for example, be a dialog in the tortoisesvn settings that
says:
For items that were remotely locked at last update:
[X] Use the gray icon
[X] Set the read-only bit
By default the new feature would be disabled, so as not to bother
existing users who already have a useful workflow. But the feature is
present to help facilitate communication of locks for people who want
that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 30 19:48:24 2006