2008/7/29 wbaron <Wolfgang_Baron_at_gmx.de>:
> On 28 Jul., 17:06, "Andy Levy" <andy.l..._at_gmail.com> wrote:
>> On Mon, Jul 28, 2008 at 10:46, wbaron <Wolfgang_Ba..._at_gmx.de> wrote:
>> > Overlay icons, properties and "check for modifications" only show the
>> > local lock status of files. That's ok, if you share your woking
>> > directory among all users, but not, if you use a server. Not instantly
>> > seeing the lock status will cause frustration in the team, because
>> > things are never what they seem to be.
>>
>> > The only way to really see locks, is to "check for modifications" and
>> > then click on "Check repository". The locking information, which is
>> > displayed there is the one you want to see all the time, so that's the
>> > information, which should be updated, whenever the local status is
>> > being refreshed. I know this slows down display a bit, but that could
>> > be minimized by the cache.
>>
>> The base Subversion libraries do not cache lock information. It really
>> isn't a good thing to attempt to cache, and it would slow things down
>> a lot more than you think. What happens on a slow network connection?
>> Or working offline entirely?
>
> That's why I suggested timeout in both directions. If the user
> requests the information in a high frequency, he is willing to wait
> and the other timeout prevents things to slow down too much. As
> TSVNCache is a process with man threads anyway, you would never have
> to wait, but let the information be kept current in the background.
Lock information can only be requested one file at a time. So that is
a server round trip for every file in your working copy. Many users
have working copies with thousands, even hundreds of thousands of
files. Just getting the info hopelessly inefficient unless subversion
grows a new feature to retrieve the lock status for a whole directory.
And that would be a request for the subversion devs, not here.
>> The only way to truly know lock status is to check with the
>> repository. As soon as that check is completed, the information is
>> potentially invalid as things can change. Locks are not like commits -
>> locks don't change the state of the repository.
>
> True, but the potentially invalid information does not matter, because
> if it is invalid, someone else has just locked the file very shortly
> before yourself, you will accept the lock failing, although you did
> not see it. However, if the lock failed, because you did not see it,
> although the file was locked for a few days, you start complaining,
> that you want to use a different VCS.
If the file is locked, then it is locked no matter which VCS you're
using. Another VCS may tell you in advance about the lock but that
won't speed up your development because you still have to wait for the
file to be unlocked.
Are you are working on binary files or text files? Do you really need
to use locking? VSS users often think they do, but it's not the only
way of working:
http://svnbook.red-bean.com/en/1.4/svn.basic.vsn-models.html
> The fact is, that TortoiseSVN
> *never* displays the relevant information (unless, like noted, all
> users work in the same working directory, but then you wouldn't use
> SVN anyway and should think about changing your career).
Right. I'm glad you're not going down that avenue :-)
>> I fail to see how this "breaks" teamwork. If you attempt to lock a
>> file that's already locked, you'll be told that it's locked and your
>> lock attempt will fail. If a file is locked, then an update will get
>> you the latest version that's in the repository - personally, I don't
>> care what another person's changes are until they're committed, so
>> what's in the repository is what's important to me.
>
> Shure, but if your locks regularly fail, although you did not see
> them, you are going to hate using SVN. Doing "ToroiseSVN/Check for
> modifications/Check repository" all the time is way too clumsy.
If your locks are failing regularly then your team are simply not
talking to each other. You are presumably using locking because you
have unmergeable files and you *have* to lock, yet different team
members are trying to work on the same file at the same time. It
sounds like you are asking for a solution to the problem "tell me what
everyone else is working on" rather than anything to do with version
control.
There are other solutions you might look at - a post-lock hook on the
server which emails everyone when a lock is taken out or released
would be one way of propagating the same information.
> I am the one that has to bring SVN to my team and I am having trouble
> finding acceptance for this shortcoming (we used VSS until now (yeah,
> yuck, sorry for that bad word, but that's the way it was and I am
> trying to change that)).
You are not alone. There was a post only a couple of days ago from
someone else taking a lot of flack from his team, because they love
VSS and want Subversion to *be* VSS. Small comfort, but a lot of the
problem is in user-education rather than changing the fundamental
concept of the VCS. The plain truth is that subversion's locking does
not lend itself to the use you would like to put it.
> Am I reaching any developers here that might include this very nice
> feature into a future release or is this the wrong place to post?
I am a documenter, not a coder. It is the right place to post, but I'm
afraid the answer will still be no.
Simon
--
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-07-30 01:00:32 CEST