Mark Phippard wrote:
> SteveKing <steveking@gmx.ch> wrote on 04/14/2005 12:02:59 PM:
>
>
>>As you might have noticed, the discussion about how/why/if ever/when to
>>show an overlay is quite controversial. And the discussion threads have
>>become quite large and hard to follow already. So, to prevent a
>>discussion about things that aren't even possible I'd like to summarize
>>some things here.
>>
>>Subversion 1.2 will have locking. It works like this:
>>- an svn:needs-lock property can be set on files, which then Subversion
>>makes readonly to indicate that a user has to get a lock on such a file
>>first. Such a file can't be committed if the working copy doesn't have
>>the lock first.
>
>
> This isn't completely true. You can still manually flip the read-only
> bit, edit and commit the file without ever acquiring a lock. Of course if
> the file were locked to someone else, you could not commit, but Subversion
> does not force you to obtain a lock.
No, if the svn:needs-lock property is set, you can't commit it without
aquiring a lock first. The repository will reject such a commit.
> Also, files can be locked even if this property does not exist.
That's true.
>>- is a file conflicted? Not so important information. You can see that a
>
>>conflict occurred in the progress dialog when you do an update too, and
>>you can't commit a conflicted file. So there would be no real harm if
>>that overlay would go down the drain.
>
> I disagree. Finding conflicts in order to edit and resolve them would be
> a real pain without the decorator.
That's why I said 'no _so_ important' - it still is usefull though ;)
>>- is a file added? Not really important. A 'modified' overlay would be
>>enough here.
>
> Agree,
I'm currently working on the readonly overlay, replacing the 'added'
overlay with it.
> I do not have an opinion on what icon to use, but I agree for the need.
> Also, clearly the issue is as simple as the file being read-only, which is
> good for performance reasons. The fact that it is read-only because of
> that property is kind of irrelevant because the same issues/problems would
> apply to any read-only file.
True. I just hope that Subversion will extend the svn_wc_entry_t struct
with the filestat information. Otherwise I have to do a filestat again
to find out if a file is readonly or not.
>>About having that overlay propagate up in the tree: I don't think that
>>would be very helpful.
>
> Definitely agree!
>
>
>>- Do I have files locked? Also an important information. Not so
>>important as for e.g. VSS since other users can steal a lock from you if
>
>
>>you're too lazy to give the lock back, but still you should know that
>>you have some locks left in your working copy.
>
>
> PVCS lets you steal locks, I think that all locking tools do. I think the
> presence of this feature in SVN is being blown out of proportion.
Well, that depends on how the locking is implemented. Subversion never
intended to *enforce* something. The whole locking feature is
implemented as a help for users, some kind of communication.
> I still think you could just pass on this whole issue and not touch the
> decorators in this release. Get the functionality in place and see what
> comes of it. Clearly the majority of people contributing to this
> dicussion are confused about one aspect or another of the feature. It
> will be easier to get real discussions when people are using it. And if
> no one uses it, then it gets even easier!
Well, the 'readonly' overlay already was asked for by I'd say important
people (the person responsible for usability at collab.net, Nina Wishbow).
Sure, it won't help much for IDE's which open many files of a project
which reside in several subfolders. But it *will* help those users who
edit single files (e.g. photoshop files, word documents, ...) a lot.
And let's be honest: the whole locking stuff is made for them, not for
programmers who edit textfiles which are mergeable and shouldn't be
locked anyway.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu Apr 14 19:26:42 2005