On Nov 13, 2007 8:47 PM, Moore, Tom <Tom.Moore@aig.com> wrote:
> I think you may have missed my point. Let me try to restate.
>
> You are right on the attribute svn:needs-lock scenario. It will always
> be read only unless a lock is set. So lets forget that scenario.. I went
> off on a tangent while trying to present the case.
>
> The point is that lock data is available in Subversion.
Right, but not to the Subversion client, since you need to contact the
server anyway to get acurate information.
> It is not
> explicitly made visible to the user at points where it would be useful
> (on update, checkout, etc.)
Right, because at that point of time it's not available to the
Subversion *client*.
> Instead the user is forced to jump through
> additional hoops when they shouldn't have to.
Yes they should. The word 'accurate' is key here: there's no way the
client can give the user accurate information. The server however can,
meaning that - for accurate info - you'll always need to contact the
server.
> Or in the case of the
> commit failure message, its not a clear message. I can't tell you how
> many users in the past have come to me saying "I got an error" and they
> never even read the whole message.
Though we do have issues with error messages being unclear, not
reading them is not really our issue, is it? :-)
> >But the instant that update is complete, any lock data can be out of
> >date. One should always check w/ the server (svn st -u) to learn the
> >current lock situation for a file, not rely upon local WC info.
>
> The converse to this is true as well. The moment the svn st -u is done,
> any lock data can be out of date.
Right. Locking isn't a replacement for communications within the team.
It's there to help you prevent your users shoot themselves in the
foot. Chances of 'svn st -u' being incorrect right after you get the
output are far smaller however than 'svn st' would be (ie without
contacting the server).
> The system should fail "safe" and if
> it detects a lock on update (or checkout) then it should note it and
> record that in the working copy (which would make it easier for clients
> like Tortoise to then display the lock).
Nope. It does not and will not. That's by design. The only way to get
an *accurate* overview is by contacting the server...
> If the working copy indicates
> a lock, even though the lock has been released since the last update,
> that's the "safe" failure as it alerts the user to a potential problem
> before it occurs.
So will having svn:needs-lock, because then the users can't modify the
file without getting a lock on it first...
> The locked status in the working copy would tell the
> user to do one of the following:
>
> 1) Go talk to the person who has the file locked.
> 2) Wait and later try a svn update or status -u on the file to see if
> the lock has been released
> 3) Choose to break the lock.
>
> I'm not advocating putting more restrictions on the file modification
> process. I'm advocating enhancing the existing commands to provide data
> that is already captured in a manner that is easily understood by the
> end user.
Right, but that data would give the user an incorrect view of the
situation, because it might suggest to said user that if the working
copy *doesn't* show a lock, the file will probably be unlocked: this
isn't correct.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 13 22:02:35 2007