Simon Large wrote:
> Bill.Hughes wrote:
>> 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.
>
> But you do need to distinguish between versioned files which you don't
> have a lock for, and unversioned files, otherwise it looks like all
> unversioned files need locking too.
Sorry if I was unclear - I was suggesting that in this case the 'in
subversion' means 'you need a lock'.
> And that makes this virtually the
> same as case 2. Files that you do hold a lock for show normal
> subversion statuses. If you have a special overlay to indicate that
> you hold a lock, then it prevents 'in
> subversion/modified/conflicted/added/deleted'
> from showing. If you hold the lock then you _can_ edit them,
> so you are
> presumably interested in the status.
I agree - if you have a lock then the normal ('in svn') overlay should
appear - I was meaning that you only need an overlay to indicate a file for
which you have a lock but that you haven't yet changed. If it's not 'in svn'
you must have a lock.
>> 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.
>
> It seems that these can be handled simply by adapting the icon set. In
> case 1, the insubversion overlay could be adapted to show
> that you hold
> the lock - green padlock? and the new read-only overlay could be an
> unobtrusive symbol (a key ?) meaning that you need to unlock.
>
> In case 2, the overlays are as they are now, but the new read-only
> overlay would be more visual - no entry sign.
>
> Simon
In case 1 'in subversion' would mean you _didn't have a lock - in that case
I'd replace 'in svn' overlay with 'no entry', you can't edit it until you
obtain a lock. In case two you'd show 'no entry' for files where you know
another wc has the lock.
To recap, in Case 1 the default status of a versioned file should be 'you
need a lock' (aka 'no entry') and not 'in svn'. In case 2 the default status
remains 'in svn'.
If you see a 'no entry' sign then you know you can't edit it, but it's in
svn. If you see an 'in svn' overlay then you assume you can edit it, if you
see another overlay you _know_ you can edit it. It's the middle situation
where we have a problem.
This doesn't remove the problem of incomplete information, but changing the
default assumption for a repo/wc may make things easier some of the time.
BTW I suggest a green key, not a padlock, you have the magic token to open
the file.
I'm beginning to hate locking.
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 16:39:13 2005