[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[TSVN] What to see immediately?

From: SteveKing <steveking_at_gmx.ch>
Date: 2005-04-14 18:02:59 CEST


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.
- A file can be locked by a user. That lock isn't assigned to the user
directly but to the working copy. Because a user can have several
working copies (at work, at home, ...).
- To find out if a file is locked in another working copy, the
repository has to be contacted and asked for that information.
- The information if a file is locked in the current working copy can be
done without contacting the repository.

So, what information do we have to present to users directly (i.e. with
overlays) and what information isn't that important so the user can ask
for that information through a command?

- 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!
- 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.
- is a file added? Not really important. A 'modified' overlay would be
enough here.
- 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!).

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
and the editor will offer you an alternative location to save the file
to. But that might be too late - you already spent time editing the
file. And if someone else locked that file and edited it, your changes
are lost. The problem here is: it's an important information, but an
overlay for this won't really help. If you open a project in an IDE, you
don't see the overlays there, and the files in that project might be
spread over several folders. So you wouldn't even see it in the explorer
right away.
But, I still want to see right away if I have to get a lock on a file or
not to edit it. So I know I have to edit a file, I browse to it in the
explorer. Do I have to lock it? I can't see it without an overlay right
away. I could try to just lock it and check if the lock succeeds - IMHO
not a good way.
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 ;)
About having that overlay propagate up in the tree: I don't think that
would be very helpful. The svn:needs-lock property will be set on all
binary files, and usually you don't edit all binary files in a folder at
once. So there will always be some readonly files somewhere in your
working copy and that propagated overlay doesn't really tell you anything.

- 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.
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.
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?


P.S. Please let's keep this discussion about the subject. I don't want
to hear about Subversion not doing locking right, TSVN better use ACL's
instead of the readonly flag, implementing our own locking which is
better than the one Subversion's doing, ... - TSVN is a Subversion
client and we have to deal with what exists. I also don't want to hear
'users won't get that right' - either provide a real example why users
might have problems or don't comment at all.

   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 18:03:14 2005

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.