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?
> Can a lock be a difference between the repo and my WC? That's not
> the way I think I would see it.
> If I lock a file it's then also locked in the repo; no diff there.
Agreed.
> If someone else has locked a file in the repo I can't see that due to
> the way it's implemented now, otherwise maybe it could be viewed as a
> diff.
Just because the difference isn't obvious doesn't mean it doesn't exist, or
that it's not important.
> If svn:needs-lock is set, it's both in my WC and the repo, no diff.
>
> Following the metaphore we should not implement overlays for locking.
> Maybe this would be a good starting point? Then, if during usage we
> find users being very annoyed with missing to lock files with
> svn:needs-lock we could alter the metaphore to also include
> displaying status of files/folders (at least for some use-cases) and
> take it from there.
>
> What do you think?
I disagree, the metaphor is inadequate - the overlays can also be regarded
as providing information that is useful about the files.
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:
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.
Why does tsvn try to commit read-only files, this could be handled
gracefully at the client end after all?
Bill
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
*** Confidentiality Notice *** Proprietary/Confidential
Information belonging to CGI Group Inc. and its affiliates
may be contained in this message. If you are not a recipient
indicated or intended in this message (or responsible for
delivery of this message to such person), or you think for
any reason that this message may have been addressed to you
in error, you may not use or copy or deliver this message
to anyone else. In such case, you should destroy this
message and are asked to notify the sender by reply email.
Received on Thu Apr 14 15:37:33 2005