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
> 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.
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.
> I don't use GUI clients much, but I thought someone mentioned earlier
> 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.
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.
I can (and am currently) living without this feature and have no plans
to convert back to ClearCase.
I would like to still see the CHANGED status cached if possible, since
there seems to be much less objection to this issue.
Kevin R.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 29 20:41:36 2007