Bill.Hughes@cgi-europe.com wrote:
> Nicklas Norling wrote:
> > Suppose we assume that we want to visually diff between the
> > repo and the WC by using overlay icons, what would that hint me
> > about locking overlay?
> <snip>
> I disagree, the metaphor is inadequate - the overlays can also be
> regarded as providing information that is useful about the files.
>
Hmm, does that mean you think the metaphor is correct if it includes the
files/folders state? I can agree
with that but we don't have anything like this now right? What state
would you propose to display?
svn:needs-lock?
> Ideally I think there should overlays for files that I have locked and
> files that others have locked, this should cover everything. That's
> not practicable, unfortunately.
>
> I wonder if we may be conflating two situations which required
> different responses:
>
No, those are use-cases, different usage of the application, kind of
independant of the metaphor.
The metaphor still stands (if one agrees upon it) independant of use
cases, otherwise you'll
end up with a inconsistent UI that will confuse end users.
> Case 1: most files are binary and need a lock to be worked upon.
> Case 2: most files do not need to be locked in order to be updated.
> In Case 1 my expectations would be such that only an indication that I
> have a lock would be useful - all other files are assumed to require
> locks but I don't have them.
>
> In Case 2 I would expect all files to be available for updating and
> would only expect to see indicators for those files that I can't change.
>
> The default cases are different.
> This doesn't help where the both cases are almost equally likely, I
> think that perhaps it should be configurable. This could then lead to
> considering that this sort of configuration should be handled at the
> repo level, and this dictates the responses of TSVN when working on a
> wc checked out from that repo. I.E. the 'balance' of the repo is
> decided at creation and propagates to the wc. This would allow
> different repos to have different setups on the same pc - you could
> work on two projects which have different locking paradigms. The
> configuration could decide which overlay wouldn't be shown - pick two
> of 'added', 'you have a lock' and 'you need a lock' according to your
> project requirements.
>
> I don't really like this but I can see an argument for it, it feels
> like it's crossing to far into svn rather than tsvn to me, but then I
> think that comes from the trying to support locking, it's bound up
> with repo config, not client.
>
Following the metaphor I'd have to ask why this should be implemented
using overlays?
I see no convincing argument for that.
The 'commit' dialog is an awfully powerful tool displaying all changes
recursively in your
WC. Could that not be the right place for finding out locking information?
The overlays only give you info in the folder you have open and to me is
used for another
type of work, namly working on files in a folder, but it might only be
me of course.
> Why does tsvn try to commit read-only files, this could be handled
> gracefully at the client end after all?
>
> Bill
>
I think relying on the read-only attribute is the wrong way to go. I'm
fairly certain svn will
eventually expand to version (or at least carry) information about file
attributes (ACLs),
that would render such a solution interim at the best.
I can see a strong argument being built around svn:needs-lock and
displaying it as an
overlay. Maybe a metaphor should include at least that property.
/Nicke
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu Apr 14 17:09:17 2005