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.
Also, files can be locked even if this property does not exist.
> - is a file versioned? That information is crucial. It tells which
> folders/files are under version control and that you can't just
> rename/move/do other things with the explorer but you must use the TSVN
> commands to do such things.
> - is a file modified? Important information. It tells you that you
> should commit the modifications you've made. If you don't commit those
> changes, you have no backup!
Absolutely.
> - 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.
> - is a file added? Not really important. A 'modified' overlay would be
> enough here.
Agree,
> - is a file/folder deleted? Important information. If you delete a
> folder in Subversion, the folder still exists and you can still see the
> folder in the explorer. Without the deleted overlay, users might get
> confused (I know I was first!).
Definitely agree!
> Now for the new locking information:
> - Do I need to Lock a file first before editing? Important information.
> Some editors don't warn you that a file is write protected and let you
> change it. Only when you try to save it you will get an error message
> So I suggest adding an overlay for that. Let's call it 'lock needed' and
> use a key as symbol (other suggestions are welcome of course). That
> overlay would show if a file is versioned and would otherwise have the
> 'normal' overlay (green checkmark). Other status will override that
> overlay (i.e. 'modified' has priority over that overlay, because if such
> a file is modified you've screwed up badly ;)
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.
> 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.
> So, another overlay for this? Maybe, I'm not sure about that. If we do
> so, this overlay would have to be propagated up the tree and be shown on
> parent folders like the 'modified' overlay.
I do not think the overlay is critical, but it would be nice to have. It
would certainly look better for your green key to turn into a padlock when
you take the Lock option! I also agree that if we do use this overlay, it
has to propogate.
> But usually, you don't lock files you don't want to edit (if you do so,
> you might get trouble with your teammates!) so you know which files you
> have locked. And of course, you will see the locked files in the commit
> dialog (not implemented yet, but soon). So that might be enough?
Comments?
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!
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
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:10:40 2005