SteveKing wrote:
> Mark Phippard wrote:
..snip..
>>> - is a file added? Not really important. A 'modified' overlay would
>>> be enough here.
>>
>> Agree,
>
> I'm currently working on the readonly overlay, replacing the 'added'
> overlay with it.
That seems the best compromise available.
>> 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.
>
> True. I just hope that Subversion will extend the
> svn_wc_entry_t struct
> with the filestat information. Otherwise I have to do a
> filestat again
> to find out if a file is readonly or not.
>>> About having that overlay propagate up in the tree: I don't think
>>> that would be very helpful.
>>
>> Definitely agree!
Hmm you could _almost_ mark the folder as conflicted if it's not able to be
committed, it's a change to the meaning of 'conflicted' but not totally
unreasonable.
>>> - 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.
>
> Well, that depends on how the locking is implemented.
> Subversion never
> intended to *enforce* something. The whole locking feature is
> implemented as a help for users, some kind of communication.
I remember a few queries from people whose managers want a system that does
enforce locking, I suppose SVN just won't be suitable. Different usage
patterns and son on.
>> 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!
>
> Well, the 'readonly' overlay already was asked for by I'd say
> important people (the person responsible for usability at collab.net,
> Nina Wishbow).
> Sure, it won't help much for IDE's which open many files of a project
> which reside in several subfolders. But it *will* help those
> users who
> edit single files (e.g. photoshop files, word documents, ...) a lot.
> And let's be honest: the whole locking stuff is made for
> them, not for
> programmers who edit textfiles which are mergeable and shouldn't be
> locked anyway.
Unless that's their working practice. I think it's dumb too, but it happens.
I'd like to just make sure I understand a few things properly:
A commit of a read-only file will fail.
A file with svn:needs-lock will be checked out as read-only until a lock is
obtained.
A lock can be obtained for any file, even if it doesn't have svn:needs-lock.
If the above are all true then why not treat all read-only files as having
svn:needs-lock, even if it's not actually set by the repo? Show all
read-only files with an icon meaning 'not committable' and allow the wc to
get a lock in order to commit.
It seems that the wc can't know the lock status of a file - it may have a
lock for a file but this may have been stolen and the wc cannot know this.
The only time the wc can be reasonably certain of a files lock status is
while communicating with the repo. (Commit/check/get lock etc.)
Given the comments in other messages that SVN doesn't actually enforce locks
if you manually change a files read-only status perhaps tsvn should check
for this too, until svn does implement it.
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 Fri Apr 15 11:24:35 2005