"Brian W. Fitzpatrick" <fitz@collab.net> writes:
> On Feb 2, 2005, at 4:49 PM, Philip Martin wrote:
>
>> "Brian W. Fitzpatrick" <fitz@collab.net> writes:
>
>>> - If svn:needs-lock is unset in wc, but update sets it: Set file to
>>> read-only.
>>
>> 1. Even if the file has local mods? I wonder if 'svn revert' works on
>> Windows if the working file is read-only.
>
> If the file has local mods, we should either do nothing or error out.
> What do you think?
I don't think an error would be appropriate as I don't see the user as
having done anything "wrong".
I suppose 'svn revert' could make such files read-only.
>> 2. What about:
>>
>> svn lock foo
>> svn ps svn:needs-lock '*' foo
>> svn ci --no-unlock foo
>> svn up -rCOMMITTED-1 foo
>> svn up -rHEAD foo
>>
>> Is the -rCOMMITTED-1 update allowed?
>
> Yes. That would effectively remove svn:needs-lock and flip the file
> back to read-write.
>
>> If so, then the -rHEAD update
>> causes svn:needs-lock to become set while the working copy already
>> holds a lock.
>
> Do you think that that's a problem?
I think it's an exception to your proposed rule to make files
read-only if update sets svn:needs-lock.
>>> Propset:
>>> - Setting the svn:needs-lock property sets the file to read-only
>>> (It also canonicalizes the value to '*')
>>
>> 1. Not if the file is locked in the current wc.
>
> Right.
>
>> 2. What about schedule add files? I don't think they can be locked so
>> they should remain read-write.
>
> I agree. This will be one of the cases where the file will be set to
> read-only only on commit.
If it turns out that such files can be locked, and they get committed
with --no-unlock, then they should remain read-write.
>> repos-to-wc or wc-to-wc copy:
>> - Ensure that the copy is read-write even if svn:needs-lock is set
>> as this is another schedule add case.
>
> And then flip to read-only on commit, right?
ditto
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 3 21:05:26 2005