> -----Original Message-----
> From: kmradke@rockwellcollins.com
> [mailto:kmradke@rockwellcollins.com]
>
> Les Mikesell <lesmikesell@gmail.com> wrote on 11/29/2007 12:50:37 PM:
> > kmradke@rockwellcollins.com wrote:
> > >>
> > >> Relying on cached lock information implies that you do not care
> > >> about locks in the first place.
> > >
> > > There is a definite disconnect here somewhere. I'll
> agree that you
> > > have no need for the usage case I (and others) have described
> > > multiple
>
> > > times.
> >
> > The part that I don't get is why you don't set needs-lock if your
> > intent
>
> > is to communicate the fact that changes to a file will be
> difficult or
> > impossible to merge even if this is a temporary situation. This is
> > what
You are (effectively) suggesting either:
1. Access to that file be serialized as policy (permanent use of the
property), or
2. To temporarilly lock the file, the user will create at least two
extra revisions, assuming you know exactly which files need to be locked
before you act. More likely, several revisions will be generated as you
realize there are other files that need to be modified. This to me is
massively inefficient and makes absolutely no sense.
Now, given, if the change in question gets beyond two files, it is
probably worth a task branch. Anything less than that, and a branch is
overkill.
>
> > should tell others that they need to be concerned about
> locks, whereas
> > the temporary existence of a lock has no such meaning even
> though you
> > might think it does and you might sometimes be right.
>
Please explain why the temporary lock feature exists. I thought I knew,
but I am beginning to suspect I am incorrect.
> Hmmm... That would force the users to update their working
> copy to get the (temporary) needs lock property change. It
> would be an option, but still not as nice as just allowing me
> to re-visit my status information off-line in a
> consistent/supported way.
>
> It may be incorrect, but I have users that assume when the
> "get lock" is done on a non needs:lock file, others are made
> aware of this. This is probably a side effect of having more
> with ClearCase backgrounds instead of CVS backgrounds...
>
> I suppose I could write a hook script to disallow locks on
> non needs:lock files indicating the user needs to add the
> property before trying the lock, but users hate these
> multi-step processes.
Sounds like a fair amount of workaround, doesn't it?
> > I don't use GUI clients much, but I thought someone
That is evident.
> mentioned earlier
That was me, and I think it is displayed by way of checking the file's
read/write status and displaying an icon if it is read-only. This is,
of course, easily overriden by manually making the file editable.
> > that the needs-lock property is picked up, cached, and made visible
> > already. Is there some reason this existing mechanism doesn't work
> > for temporary situations the same as for file types that
> are always a
> > problem to merge?
>
> It works, it just could be easier/friendlier to the user.
Subversion _only_ caches locks owned by the person who has the lock,
nobody else sees it. Ankh has an icon for that scenario, so I know what
I locked. Tortoise also shows me the lock. Nifty, eh? It would be
nice if I could see a similar icon for things locked by others, with a
nice mouse-over text with the lock reason (and creation timestamp),
which is currently supplied by whomever grabs the lock.
>
> Locking isn't the only bit of status information that has
> potential for being cached, but it definitely is the one some
> people think isn't as useful as some of us other people do.
Understatement.
> I would like to still see the CHANGED status cached if
> possible, since there seems to be much less objection to this issue.
In my scenario, there wouldn't be a changed status because the lock
information would come with a regular update operation (sure, with a new
API or parameter, leaving existing interfaces intact). However, I have
no problem with your idea, Kevin. That would be useful as a very low
bandwidth server check by grabbing the server status.
>
> Kevin R.
--
David Bicking
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 29 21:07:23 2007