You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Brian W. Fitzpatrick" <fi...@collab.net> on 2005/02/02 22:05:53 UTC
Re: Locking: RFC: svn:needs-lock behaviors (Updated)
On Wed, 2005-02-02 at 16:00, Mark Phippard wrote:
> "Brian W. Fitzpatrick" <fi...@collab.net> wrote on 02/02/2005 04:53:37 PM:
>
> [snip]
>
> > Propset:
> > - Setting the svn:needs-lock property sets the file to read-only
> > (It also canonicalizes the value to '*')
>
> Before setting the file to read-only, shouldn't it check to see if it is
> locally modified?
Hmm. I'm not sure about that--if the prop is set, and the user has
local mods, isn't it safe to assume that the user is doing it
intentionally?
> You do not mention unlock. But I would assume if you run a command that
> unlocks a file with this property set, whether it be the unlock or commit
> command, that it would set the file to read-only?
Doh. Of course I skipped the obvious. Here's the update list of
behaviors (I've not included commit as that will call unlock):
svn:needs-lock behaviors:
=========================
Checkout:
- If svn:needs-lock is set on a file when the file is checked out, set
the file to read-only.
Update:
- If svn:needs-lock is unset in wc, but update sets it: Set file to
read-only.
- If svn:needs-lock is set in wc, but update unsets it: Set file to
read-write.
- If svn:needs-lock is set or unset in both places: Do nothing.
Propset:
- Setting the svn:needs-lock property sets the file to read-only
(It also canonicalizes the value to '*')
Propdel:
- Removing svn:needs-lock sets the file to read-write.
Propedit:
- If the property is changed via propedit, we need to canonicalize it
to '*'.
Lock:
- If svn:needs-lock is set, the file is set to read-write.
Unlock:
- If svn:needs-lock is set, the file is set to read-only.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking: RFC: svn:needs-lock behaviors (Updated)
Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On Feb 3, 2005, at 2:03 PM, Ben Collins-Sussman wrote:
> On Feb 3, 2005, at 12:54 PM, Philip Martin wrote:
>> Far better to force the user to explicitly break
>> the lock before allowing the commit.
>
> So your proposal is that when a new directory is added to a
> commit-txn, the filesystem should require token-authn for all locks
> that exist below the path, yes? (And of course, the locks would all
> be on nonexistent paths.)
>
> Good news, the fs is already doing this. Look at
> libsvn_fs_base/tree.c:2864 in the locking branch. I assume
> libsvn_fs_fs is doing the same. (fitz?)
libsvn_fs_fs/tree.c:2128.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking: RFC: svn:needs-lock behaviors (Updated)
Posted by Ben Collins-Sussman <su...@collab.net>.
On Feb 3, 2005, at 12:54 PM, Philip Martin wrote:
>
> Whether the commit breaks the foo/zig lock, or whether the lock
> remains but is unuseable, it looks like a problem to me. It's a
> problem because the user making the commit doesn't know about the
> foo/zig lock,
Not necessarily true. If they run 'svn st -u', they'll see that it
exists.
> they are unaware that it exists before the commit and
> they don't know that the commit has stranded or broken it.
You seem to be bothered by the idea that a lock might be stranded in
the repository... that the user who created it will abandon the token,
or that the repository lock will sit and rot for ages. But I doubt
that will be a problem in practice. 'svn st -u' will show that lock
(so will 'svnadmin lslocks'), and eventually somebody will notice it
and just kill it.
> That sort
> of inadvertent behaviour is exactly what locking is supposed to
> prevent, isn't it?
Well, not really. Locking is supposed to prevent people from wasting
time in writing unmergeable changes.
> Far better to force the user to explicitly break
> the lock before allowing the commit.
So your proposal is that when a new directory is added to a commit-txn,
the filesystem should require token-authn for all locks that exist
below the path, yes? (And of course, the locks would all be on
nonexistent paths.)
Good news, the fs is already doing this. Look at
libsvn_fs_base/tree.c:2864 in the locking branch. I assume
libsvn_fs_fs is doing the same. (fitz?)
So, maybe there's nothing to argue about, then? :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking: RFC: svn:needs-lock behaviors (Updated)
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:
>> The conflict arises if foo/bar is allowed to be committed, one might
>> expect it to be possible to make this commit as the the foo/bar lock
>> is available. However, if the commit is allowed then the foo/zig lock
>> gets "stranded", as it's inside a directory that cannot be committed.
>
> There's nothing wrong with locks being 'stranded' (or 'made defunct',
> is the terminology we use in the locking spec.) It's no different
> than somebody forcibly breaking a lock.
I was assuming that foo/zig would remain locked as it is not involved
in the commit txn, so the repository would still have a lock on a path
that does not yet exist, the wc would still hold the lock token, but
the token would be under a directory that cannot be committed because
it would be a conflict. I suppose the repository could break the
lock, but I don't like that design any better.
> The whole token-in-wc design
> assumes that a token can become defunct at any time. 'svn up' will
> remove defunct tokens.
'svn up' is going to generate a conflict on 'foo', I suspect the user
will abandon the directory and the lock token.
> So I'm not sure if there's really a problem here.
Whether the commit breaks the foo/zig lock, or whether the lock
remains but is unuseable, it looks like a problem to me. It's a
problem because the user making the commit doesn't know about the
foo/zig lock, they are unaware that it exists before the commit and
they don't know that the commit has stranded or broken it. That sort
of inadvertent behaviour is exactly what locking is supposed to
prevent, isn't it? Far better to force the user to explicitly break
the lock before allowing the commit.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking: RFC: svn:needs-lock behaviors (Updated)
Posted by Ben Collins-Sussman <su...@collab.net>.
On Feb 3, 2005, at 10:46 AM, Philip Martin wrote:
>
> # lock foo/bar
> svn mkdir wc1/foo
> touch wc1/foo/bar
> svn add wc1/foo/bar
> svn lock wc1/foo/bar
>
> # lock foo/zig
> svn mkdir wc2/foo
> touch wc2/foo/zig
> svn add wc2/foo/zig
> svn lock wc2/foo/zig
>
> Both foo/bar and foo/zig are locked, I don't think there is any way to
> detect the "conflict" at this stage.
>
> # try to commit foo/bar
> svn commit wc1/foo/bar
Do you mean 'svn commit wc1' here? I think commit will choke if you
try to commit a target whose parent is scheduled for addition. You'd
have to commit both foo and bar.
>
> The conflict arises if foo/bar is allowed to be committed, one might
> expect it to be possible to make this commit as the the foo/bar lock
> is available. However, if the commit is allowed then the foo/zig lock
> gets "stranded", as it's inside a directory that cannot be committed.
There's nothing wrong with locks being 'stranded' (or 'made defunct',
is the terminology we use in the locking spec.) It's no different than
somebody forcibly breaking a lock. The whole token-in-wc design
assumes that a token can become defunct at any time. 'svn up' will
remove defunct tokens.
So I'm not sure if there's really a problem here.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking: RFC: svn:needs-lock behaviors (Updated)
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:
> This isn't about conflicts,
I think it's a conflict, of sorts.
> or even about whether repository paths
> exist. It's about whether locks already exist or not. If a user
> tries to lock a repository path and there's already a lock present, an
The lock is not already present.
> error is thrown. The only way to resolve the situation is to forcibly
> destroy the pre-existing lock.
My question is when is the conflict detected:
# lock foo/bar
svn mkdir wc1/foo
touch wc1/foo/bar
svn add wc1/foo/bar
svn lock wc1/foo/bar
# lock foo/zig
svn mkdir wc2/foo
touch wc2/foo/zig
svn add wc2/foo/zig
svn lock wc2/foo/zig
Both foo/bar and foo/zig are locked, I don't think there is any way to
detect the "conflict" at this stage.
# try to commit foo/bar
svn commit wc1/foo/bar
The conflict arises if foo/bar is allowed to be committed, one might
expect it to be possible to make this commit as the the foo/bar lock
is available. However, if the commit is allowed then the foo/zig lock
gets "stranded", as it's inside a directory that cannot be committed.
I think it's a bug if this is allowed to happen.
If we allow locks on paths that don't exist in the repository then I
suggest that when adding a directory foo/ the commit has to supply all
the locks under foo/. This would mean that the above conflict is
detected when the foo/bar commit fails, and the user can resolve the
conflict by breaking the foo/zig lock, just like any other conflict.
Note that there is no conflict if foo/bar and foo/zig are both locked
in the same working copy, the client can supply both locks even if
foo/zig is not part of the commit txn.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking: RFC: svn:needs-lock behaviors (Updated)
Posted by Ben Collins-Sussman <su...@collab.net>.
On Feb 2, 2005, at 7:51 PM, Philip Martin wrote:
> Ben Collins-Sussman <su...@collab.net> writes:
>
>> On Feb 2, 2005, at 5:49 PM, Philip Martin wrote:
>>
>>> Greg Hudson <gh...@MIT.EDU> writes:
>>>
>>>> To the best of my knowledge, you should be able to lock schedule-add
>>>> files just fine. Locks apply to pathnames, not nodes or node-revs.
>>>
>>> The documentation in notes/ doesn't mention such locks, although it
>>> doesn't exclude them either, is there a plan to implement this sort
>>> of
>>> lock without node?
>>
>> The repository already allows locks on nonexistent paths. (DAV
>> clients sometimes do this as a way of 'reserving' a path.)
>>
>> I'm not entirely sure that svn_ra_lock() allows it -- we should double
>> check the three RA layers.
>>
>>> There are all sorts of corner cases: if I have a
>>> schedule add directory 'foo' and I lock the path 'foo/bar' does that
>>> stop someone else commiting a new 'foo'?
>>
>> From the repository's point of view, yes. It should enforce the
>> lock.
>
Hm, thinking about it, I'm not so sure we should allow svn clients to
lock nonexistent paths. Perhaps this feature should be like
lock-expiration: it exists in the fs API for generic DAV clients to
use, but not in the ra or client APIs.
> What about:
>
> - Directory 'foo/' is schedule add so not in the repository.
> - I lock 'foo/bar', it's not in the repository either.
>
> Can I also lock 'foo/zig'? As a user I would expect to be able to do
> that.
Well, if we decide to allow svn clients to lock nonexistent paths, then
sure, it would work.
>
> Can some other user lock 'foo/zig' from their working copy? If that
> is allowed then one of us is going to have a conflict. It might not
> be another user, it might be me attempting to lock 'foo/zig' but from
> a different working copy. How does the repository determine whether
> locking 'foo/bar' and 'foo/zig' is a conflict?
This isn't about conflicts, or even about whether repository paths
exist. It's about whether locks already exist or not. If a user tries
to lock a repository path and there's already a lock present, an error
is thrown. The only way to resolve the situation is to forcibly
destroy the pre-existing lock.
This leads to two general questions:
* do we allow 'svn lock' to operate on a URL?
* do we allow 'svn lock' to operate on a non-existent URL or
non-existent wcpath?
In both cases, there's no place to store the token that comes back.
Which means the lock can *only* be used for reserving a path. The
token would be lost, and the lock could never be used for commits. The
lock would ultimately end up being removed, rather than used.
I know cmpilato thinks it's useful to reserve a path, even if the lock
is only going to be destroyed (or stolen) later on.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking: RFC: svn:needs-lock behaviors (Updated)
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:
> On Feb 2, 2005, at 5:49 PM, Philip Martin wrote:
>
>> Greg Hudson <gh...@MIT.EDU> writes:
>>
>>> To the best of my knowledge, you should be able to lock schedule-add
>>> files just fine. Locks apply to pathnames, not nodes or node-revs.
>>
>> The documentation in notes/ doesn't mention such locks, although it
>> doesn't exclude them either, is there a plan to implement this sort of
>> lock without node?
>
> The repository already allows locks on nonexistent paths. (DAV
> clients sometimes do this as a way of 'reserving' a path.)
>
> I'm not entirely sure that svn_ra_lock() allows it -- we should double
> check the three RA layers.
>
>> There are all sorts of corner cases: if I have a
>> schedule add directory 'foo' and I lock the path 'foo/bar' does that
>> stop someone else commiting a new 'foo'?
>
> From the repository's point of view, yes. It should enforce the lock.
What about:
- Directory 'foo/' is schedule add so not in the repository.
- I lock 'foo/bar', it's not in the repository either.
Can I also lock 'foo/zig'? As a user I would expect to be able to do
that.
Can some other user lock 'foo/zig' from their working copy? If that
is allowed then one of us is going to have a conflict. It might not
be another user, it might be me attempting to lock 'foo/zig' but from
a different working copy. How does the repository determine whether
locking 'foo/bar' and 'foo/zig' is a conflict?
If the repository cannot detect the conflict I suppose it could
require all locks under 'foo/' to be supplied when using any one of
them. At least then the problem would be detected at commit time and
and the committer would need to break any locks not held.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking: RFC: svn:needs-lock behaviors (Updated)
Posted by Ben Collins-Sussman <su...@collab.net>.
On Feb 2, 2005, at 5:49 PM, Philip Martin wrote:
> Greg Hudson <gh...@MIT.EDU> writes:
>
>> To the best of my knowledge, you should be able to lock schedule-add
>> files just fine. Locks apply to pathnames, not nodes or node-revs.
>
> The documentation in notes/ doesn't mention such locks, although it
> doesn't exclude them either, is there a plan to implement this sort of
> lock without node?
The repository already allows locks on nonexistent paths. (DAV clients
sometimes do this as a way of 'reserving' a path.)
I'm not entirely sure that svn_ra_lock() allows it -- we should double
check the three RA layers.
> There are all sorts of corner cases: if I have a
> schedule add directory 'foo' and I lock the path 'foo/bar' does that
> stop someone else commiting a new 'foo'?
From the repository's point of view, yes. It should enforce the lock.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking: RFC: svn:needs-lock behaviors (Updated)
Posted by Philip Martin <ph...@codematters.co.uk>.
Greg Hudson <gh...@MIT.EDU> writes:
> To the best of my knowledge, you should be able to lock schedule-add
> files just fine. Locks apply to pathnames, not nodes or node-revs.
The documentation in notes/ doesn't mention such locks, although it
doesn't exclude them either, is there a plan to implement this sort of
lock without node? There are all sorts of corner cases: if I have a
schedule add directory 'foo' and I lock the path 'foo/bar' does that
stop someone else commiting a new 'foo'? Their 'foo' will conflict
with the 'foo' in my working copy, and resolving it will probably
cause me to loose my lock token.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking: RFC: svn:needs-lock behaviors (Updated)
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
>
> On Feb 3, 2005, at 6:56 PM, Branko Čibej wrote:
>
>> Greg Hudson wrote:
>>
>>> On Wed, 2005-02-02 at 17:49, Philip Martin wrote:
>>>
>>>>> 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.
>>>>
>>>> 2. What about schedule add files? I don't think they can be locked so
>>>> they should remain read-write.
>>>>
>>>
>>> To the best of my knowledge, you should be able to lock schedule-add
>>> files just fine. Locks apply to pathnames, not nodes or node-revs.
>>>
>> DAV lets you do that, yes, but AFAIK we decided not to allow it.
>>
>
> Funny, since I implemented it last month. :-)
I meant to say, "... but AFAIK we decided not to allow the SVN client do
do it."
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking: RFC: svn:needs-lock behaviors (Updated)
Posted by Ben Collins-Sussman <su...@collab.net>.
On Feb 3, 2005, at 6:56 PM, Branko Čibej wrote:
> Greg Hudson wrote:
>
>> On Wed, 2005-02-02 at 17:49, Philip Martin wrote:
>>
>>>> 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.
>>>
>>> 2. What about schedule add files? I don't think they can be locked
>>> so
>>> they should remain read-write.
>>>
>>
>> To the best of my knowledge, you should be able to lock schedule-add
>> files just fine. Locks apply to pathnames, not nodes or node-revs.
>>
> DAV lets you do that, yes, but AFAIK we decided not to allow it.
>
Funny, since I implemented it last month. :-)
It's pretty important to me that we end up with a "finished"
autoversioning feature as a side-effect of all this locking stuff.
That means allowing locks on nonexistent paths, and allowing a client
to create an expiring lock. If we don't have those things, some very
popular DAV clients won't interoperate.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking: RFC: svn:needs-lock behaviors (Updated)
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>On Wed, 2005-02-02 at 17:49, Philip Martin wrote:
>
>
>>>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.
>>
>>2. What about schedule add files? I don't think they can be locked so
>> they should remain read-write.
>>
>>
>
>To the best of my knowledge, you should be able to lock schedule-add
>files just fine. Locks apply to pathnames, not nodes or node-revs.
>
>
DAV lets you do that, yes, but AFAIK we decided not to allow it.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking: RFC: svn:needs-lock behaviors (Updated)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2005-02-02 at 17:49, Philip Martin wrote:
> > 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.
>
> 2. What about schedule add files? I don't think they can be locked so
> they should remain read-write.
To the best of my knowledge, you should be able to lock schedule-add
files just fine. Locks apply to pathnames, not nodes or node-revs.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking: RFC: svn:needs-lock behaviors (Updated)
Posted by Philip Martin <ph...@codematters.co.uk>.
"Brian W. Fitzpatrick" <fi...@collab.net> writes:
> On Feb 2, 2005, at 4:49 PM, Philip Martin wrote:
>
>> "Brian W. Fitzpatrick" <fi...@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
Re: Locking: RFC: svn:needs-lock behaviors (Updated)
Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On Feb 2, 2005, at 4:49 PM, Philip Martin wrote:
> "Brian W. Fitzpatrick" <fi...@collab.net> writes:
>
>> svn:needs-lock behaviors:
>> =========================
>>
>> Checkout:
>> - If svn:needs-lock is set on a file when the file is checked out, set
>> the file to read-only.
>
> 'svn update' doesn't currently work on Windows if the working files
> are read-only, you will need to add some permission changing code.
OK. I'll have to add code to accomodate that (I would assume that
there's already code somewhere to do this).
>> - 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?
> 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?
>> - If svn:needs-lock is set in wc, but update unsets it: Set file to
>> read-write.
>> - If svn:needs-lock is set or unset in both places: Do nothing.
>
> - If svn:needs-lock is set in both places and the update breaks a
> lock: Make the file read-only. Even if locally modified?
>
>> 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.
>> Propdel:
>> - Removing svn:needs-lock sets the file to read-write.
>>
>> Propedit:
>> - If the property is changed via propedit, we need to canonicalize it
>> to '*'.
>>
>> Lock:
>> - If svn:needs-lock is set, the file is set to read-write.
>>
>> Unlock:
>> - If svn:needs-lock is set, the file is set to read-only.
>
> 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?
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking: RFC: svn:needs-lock behaviors (Updated)
Posted by Philip Martin <ph...@codematters.co.uk>.
"Brian W. Fitzpatrick" <fi...@collab.net> writes:
> svn:needs-lock behaviors:
> =========================
>
> Checkout:
> - If svn:needs-lock is set on a file when the file is checked out, set
> the file to read-only.
'svn update' doesn't currently work on Windows if the working files
are read-only, you will need to add some permission changing code.
> Update:
>
> - 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.
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? If so, then the -rHEAD update
causes svn:needs-lock to become set while the working copy already
holds a lock.
> - If svn:needs-lock is set in wc, but update unsets it: Set file to
> read-write.
> - If svn:needs-lock is set or unset in both places: Do nothing.
- If svn:needs-lock is set in both places and the update breaks a
lock: Make the file read-only. Even if locally modified?
> 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.
2. What about schedule add files? I don't think they can be locked so
they should remain read-write.
> Propdel:
> - Removing svn:needs-lock sets the file to read-write.
>
> Propedit:
> - If the property is changed via propedit, we need to canonicalize it
> to '*'.
>
> Lock:
> - If svn:needs-lock is set, the file is set to read-write.
>
> Unlock:
> - If svn:needs-lock is set, the file is set to read-only.
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.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking: RFC: svn:needs-lock behaviors (Updated)
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Wed, 2 Feb 2005, Brian W. Fitzpatrick wrote:
> On Wed, 2005-02-02 at 16:00, Mark Phippard wrote:
> > "Brian W. Fitzpatrick" <fi...@collab.net> wrote on 02/02/2005 04:53:37 PM:
> >
> > [snip]
> >
> > > Propset:
> > > - Setting the svn:needs-lock property sets the file to read-only
> > > (It also canonicalizes the value to '*')
> >
> > Before setting the file to read-only, shouldn't it check to see if it is
> > locally modified?
>
> Hmm. I'm not sure about that--if the prop is set, and the user has
> local mods, isn't it safe to assume that the user is doing it
> intentionally?
>
You could also just set this at commit time. What does it buy you to set
it on propset directly?
> Doh. Of course I skipped the obvious. Here's the update list of
> behaviors (I've not included commit as that will call unlock):
>
> svn:needs-lock behaviors:
> =========================
>
> Checkout:
> - If svn:needs-lock is set on a file when the file is checked out, set
> the file to read-only.
>
> Update:
>
> - If svn:needs-lock is unset in wc, but update sets it: Set file to
> read-only.
> - If svn:needs-lock is set in wc, but update unsets it: Set file to
> read-write.
> - If svn:needs-lock is set or unset in both places: Do nothing.
>
- If svn:needs-lock is set and the lock is removed, set the file
read-only.
> Propset:
> - Setting the svn:needs-lock property sets the file to read-only
> (It also canonicalizes the value to '*')
>
> Propdel:
> - Removing svn:needs-lock sets the file to read-write.
>
> Propedit:
> - If the property is changed via propedit, we need to canonicalize it
> to '*'.
>
> Lock:
> - If svn:needs-lock is set, the file is set to read-write.
>
> Unlock:
> - If svn:needs-lock is set, the file is set to read-only.
>
>
> -Fitz
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking: RFC: svn:needs-lock behaviors (Updated)
Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On Wed, 2005-02-02 at 16:09, Mark Phippard wrote:
> "Brian W. Fitzpatrick" <fi...@collab.net> wrote on 02/02/2005 05:05:53 PM:
>
> > On Wed, 2005-02-02 at 16:00, Mark Phippard wrote:
> > > "Brian W. Fitzpatrick" <fi...@collab.net> wrote on 02/02/2005 04:53:37
> PM:
> > >
> > > [snip]
> > >
> > > > Propset:
> > > > - Setting the svn:needs-lock property sets the file to read-only
> > > > (It also canonicalizes the value to '*')
> > >
> > > Before setting the file to read-only, shouldn't it check to see if it
> is
> > > locally modified?
> >
> > Hmm. I'm not sure about that--if the prop is set, and the user has
> > local mods, isn't it safe to assume that the user is doing it
> > intentionally?
>
> Sure, but if I am editing the file, as indicated by the local mods,
> doesn't it stand to reason that I would not want the file to be made
> read-only until I commit? In your scenario, are you assuming that after
> running svn propset, I would have to run svn lock to make the file
> read-write before I commit?
Well, you *did* just set a property named "needs-lock" on the file. I
would assume that that means that the file needs to be locked before
committing, wouldn't you? :-)
Kidding aside, I think that flipping the file to read-only right away
really is the right thing to do here.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking: RFC: svn:needs-lock behaviors (Updated)
Posted by Mark Phippard <Ma...@softlanding.com>.
"Brian W. Fitzpatrick" <fi...@collab.net> wrote on 02/02/2005 05:05:53 PM:
> On Wed, 2005-02-02 at 16:00, Mark Phippard wrote:
> > "Brian W. Fitzpatrick" <fi...@collab.net> wrote on 02/02/2005 04:53:37
PM:
> >
> > [snip]
> >
> > > Propset:
> > > - Setting the svn:needs-lock property sets the file to read-only
> > > (It also canonicalizes the value to '*')
> >
> > Before setting the file to read-only, shouldn't it check to see if it
is
> > locally modified?
>
> Hmm. I'm not sure about that--if the prop is set, and the user has
> local mods, isn't it safe to assume that the user is doing it
> intentionally?
Sure, but if I am editing the file, as indicated by the local mods,
doesn't it stand to reason that I would not want the file to be made
read-only until I commit? In your scenario, are you assuming that after
running svn propset, I would have to run svn lock to make the file
read-write before I commit?
Thanks
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org