You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2004/05/26 15:38:26 UTC
Locking design (was Re: svn commit: r9885 - trunk/notes)
Why are we discussing locking design in a file, instead of on the list?
I can see the benefit of recording the outcome of a conversation in a
file, but not of holding it there. So, I'm going to have my part of the
discussion back here on the list.
On Wed, 2004-05-26 at 02:46, brane@tigris.org wrote:
> + [How about depth-0 directory locks? The use-case is to protect
> + dir props only; useful since those are not merged. --brane]
So, before we go wild with directory locks and depth indicators,
remember that locks don't interact well with our operational model.
We're going to run into corner cases like: I lock a file in a working
directory, make a copy of it, and then unlock it in one of the working
copies; the other one erroneously believes it holds a lock.
Because of that mismatch, we're probably best off keeping locks simple
("protect unmergeably files"), and not imagining new uses for them like
release branches (which are better handled through acls) and property
protection.
> read and write -- because then we'd open the door to
> implementing 'read hooks'.)
As an aside, I talked to Ben about this, and I think it's based on a
poorly-conceived and vague plan of how read hooks might be implemented.
So we shouldn't consider 'it will get us closer to read hooks' as a
motivation.
A better plan, in my opinion, is to have svn_repos_fs_commit_txn compare
the changed-path list to the lock table and reject the commit if there
are any files locked by a different working copy.
> + [Looking at this again, I find there's one big problem with using
> + the repos layer for this. It means the lock table has to be
> + exposed through the FS API.
I have no idea what you mean. here.
> How should this be implemented? As a separate BDB table managed by
> libsvn_repos? That would certainly scale, but then it might create
> - NFS problems, etc. Another idea is to use an XML file (parsed once
> + NFS problems, etc.
> +
> + [Huh? What NFS problems would it create that the repository doesn't
> + already have? Well, really. --brane]
So, Ben was theorizing that libsvn_repos could, without the help of
libsvn_fs_base, open a BDB table and use it. That's of course totally
unacceptable; we have two fully functioning FS back ends now, and one of
them isn't hamstrung by Berkeley BD's limitations.
> + [Please don't even think of anything but a FS-backend-specific
> + lookup table. Will you rewrite some text file every time a lock
> + changes? With no transaction-based consistency protection?
> + Will you let the admin edit the lock file behind a running
> + server's back? And more to the point, will you take the penalty
> + of keeping the whole lookup table in memory after we add ACL
> + lookup to it and suddenly find that 50000 ACLS are no small
> + thing? *shudder* -- brane]
Who says we're oging to put ACLs into the lockfile? I'm okay with doing
this if it happens to work, but I'm not okay with loading down the
locking design with the ACL system's requirements.
Why do we need transaction-based consistency protection?
> + [+2. Also think about optinally adding the client name and local
> + path to the locked file to the token (not only 'who', but 'where')
Ick. Repository doesn't keep track of working copies. That arrow only
goes one way. Otherwise moving working copies around becomes
inadvisable.
> + -- useful info in an in-company team. Also a note, commit-log
> + template if you will, which could be used to describe the
> + reason for the lock to other users. So not only 'who' and
> + 'where', but also 'why'.
People may find this cumbersome; I don't think other version control
systems generally have it. I'm not opposed to it unless (deep breath)
asking for a lock rationale is not the default unless specified by the
file's svn:lock-required property.
> + [Um. Only the lock owner (and an admin, yes) should be able to
> + remove a lock. Therefore a lock token should be required by
> + default. You could overroide that with "svn unlock --force".
> + Then after we add ACLs, there will also be a 'break locks'
> + global privilege -- brane]
Why a global privilege? Why not a local one?
Ben's idea was that the repository will look at the username to decide
if you own the lock. But I don't see the situation quite the same:
svn unlock file
--> transmit lock token, fail if no lock present with that token
svn unlock --force file
--> don't transmit token, always succeed if my username owns the
lock, possibly succeed (based on ACLs) if someone else owns the
lock
(If we allow multiple locks on a file, an idea which I consider really
bizarre, then there are some more corner cases to consider in the second
case.)
[Regarding the svn:lock-required property:]
> + [I suggest that this should be a read-only liveprop whose
> + value is implied by server-side configuration, and can't
> + be modified by the client. This is a repository policy,
> + not a user decision. -- brane]
So you need admin privileges to set up an unmergeable file? That's
dumb. If the user wants to manually unset the svn:lock-required
property in order to evade a lock, that's akin to rebuilding the svn
client to ignore it. We can't stop them, so there's no point in making
it harder at the expense of increased user-visible complexity.
> + Now if you _really_ need it, you can do "svn lock --force" to
> + steal the existing lock. Again, later on, the ACL can tell you
> + if a) you can steal locks at all, and b) you can steal other
> + people's, not just your own. -- brane]
I was thinking you'd do "svn unlock --force" followed by "svn lock", but
that's a bikeshed. No need to have two levels of ACLs, really; stealing
or cancelling your own locks is not an access control issue, and should
always succeed.
> + ... I suggest the update... should include lock tokens...
> + Oh by the way, all of this implies that the server never
> + transmits the lock GUID to anyone once the lock token has been
> + sent to the owner after an "svn lock", otherwise you open the
> + door to lock spoofing -- _not_ a good idea! --brane]
These things seem to contradict each other, so I think I misunderstood
the first part.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking design (was Re: svn commit: r9885 - trunk/notes)
Posted by Branko Čibej <br...@xbc.nu>.
C. Michael Pilato wrote:
><thinkingaloud>
>
>
You do the loud part pretty well, yes. :-)
>But then again ... implementing depth-infinity directory locks means
>that to implement "lock dir; unlock dir/subdir", we'll either need
>some way to indicate lock exceptions (a negation token of sorts) or
>we'll end up exploding the locks into per-resource locks table rows
>anyway, in which case directory locking is again useless.
>
>
Oh no, no exceptions. If you lock a directory, you implicitly lock all
the files, yes, but that doesn't mean you can make an exception. No, you
have to unlock the directory itself. That's SOP.
Funny thing, that in the WebDAV locking spec, too. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking design (was Re: svn commit: r9885 - trunk/notes)
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>On Wed, 2004-05-26 at 20:36, C. Michael Pilato wrote:
>
>
>>While I was kinda anti-directory-lock, I fear that by *not*
>>implementing directory locks, we're going to open up a larger can of
>>worms (from a performance and elegance standpoint). As soon as
>>UserOfLargeBinaryfulRepos realizes he can't lock his massive tree of
>>digital video resources, he'll do something worse -- recursively lock
>>each resource in that tree.
>>
>>
>
>I imagine this would only happen with any frequency if we made it easy
>to get a recursive lock.
>
>
That reminds me of a nice "feature" of Visual Studio. Its VC integration
makes it very easy for the user to "check out a project" -- literally
lock all the files mentioned in the project file. Unfortunately it seems
that's fairly common practice: "Oh, I can click that button and it
checks out everything, that's so much simpler than having to check out
every changed file separately..." -- typical developers' laziness
showing one of its eviler sides.
What I'm saying is that even if we, in the command line client or
libsvn_client, don't make it easy to recursively lock files, other tools
will. I think we should take care to not make locking operations (lock,
lookup, unlock) any worse than O(N log N). That's good design, anyway,
but I suspect that what we think of the "borderline" cases of lock usage
will hit us more often than expected.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking design (was Re: svn commit: r9885 - trunk/notes)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2004-05-26 at 20:36, C. Michael Pilato wrote:
> While I was kinda anti-directory-lock, I fear that by *not*
> implementing directory locks, we're going to open up a larger can of
> worms (from a performance and elegance standpoint). As soon as
> UserOfLargeBinaryfulRepos realizes he can't lock his massive tree of
> digital video resources, he'll do something worse -- recursively lock
> each resource in that tree.
I imagine this would only happen with any frequency if we made it easy
to get a recursive lock.
But it seems more likely that the need wouldn't arise much at all.
Until Branko said he had an interest in locking release branches (which
I don't understand as of yet), I had seen zero requests for the ability
to lock whole trees of files. Unless you plan to make unmergeable
changes to a whole tree of files (in which case you're going to use lots
of server resources making a big commit anyway, and the locking overhead
will only be commensurate with that cost), why would you want to lock
all of them?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking design (was Re: svn commit: r9885 - trunk/notes)
Posted by "C. Michael Pilato" <cm...@collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> >So, before we go wild with directory locks and depth indicators,
> > remember that locks don't interact well with our operational
> > model. We're going to run into corner cases like: I lock a file in a
> > working
> >directory, make a copy of it, and then unlock it in one of the working
> >copies; the other one erroneously believes it holds a lock.
> >
> That's no worse than breaking the lock any other way.
<thinkingaloud>
While I was kinda anti-directory-lock, I fear that by *not*
implementing directory locks, we're going to open up a larger can of
worms (from a performance and elegance standpoint). As soon as
UserOfLargeBinaryfulRepos realizes he can't lock his massive tree of
digital video resources, he'll do something worse -- recursively lock
each resource in that tree. Now instead of adding a single
locks-table item, there's a thousand. Though I suspect it will be
painful to get right, wussing out on directory locking almost feels
like a violation of our foremost win over CVS -- that we do directory
version control quite well thankyouverymuch.
But then again ... implementing depth-infinity directory locks means
that to implement "lock dir; unlock dir/subdir", we'll either need
some way to indicate lock exceptions (a negation token of sorts) or
we'll end up exploding the locks into per-resource locks table rows
anyway, in which case directory locking is again useless.
Dinner was pretty good tonight, despite having to eat it while on a
conference call. I think I'll surprise Amy by washing up the
remaining dishes. Gavin, it's sleepytime, son, not vocal-strength-test
time.
Oops. Need to stop thinking aloud.
</thinkingaloud>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking design (was Re: svn commit: r9885 - trunk/notes)
Posted by Josh Pieper <jj...@pobox.com>.
Branko ??ibej wrote:
> Greg Hudson wrote:
> >>+ Oh by the way, all of this implies that the server never
> >>+ transmits the lock GUID to anyone once the lock token has been
> >>+ sent to the owner after an "svn lock", otherwise you open the
> >>+ door to lock spoofing -- _not_ a good idea! --brane]
> >>
> >>
> >
> >These things seem to contradict each other, so I think I misunderstood
> >the first part.
> >
> >
> Yes, I wasn't quite clear. When the client sends a "current state" tree
> to the server, it should include any lock tokens it finds in the working
> copy. There can be only one of those per path, so the server can reply,
> "the lock on *this* path is stale" without having to send the lock token
> back to the client, or any client.
>
> Perhaps there's an even easier way; since an "svn st -u" would list
> locked files anyway, the client can notice that the lock is gone simply
> by the fact that it's not marked as locked in the status/update reply.
> Doesn't even have to send lock tokens to the server except on commit or
> unlock.
I think this second approach could have some problems. What if the
local working copy's lock had expired/been unlocked and another client
received the lock? When this WC sees that the file is locked, it
incorrectly assumes that it owns that lock. I think the client will
always have to submit its lock tokens to the server and have the
server check that they are still valid.
-Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking design (was Re: svn commit: r9885 - trunk/notes)
Posted by John Pybus <jo...@zoology.oxford.ac.uk>.
Branko Čibej wrote:
> Greg Hudson wrote:
>>
>> As an aside, I talked to Ben about this, and I think it's based on a
>> poorly-conceived and vague plan of how read hooks might be
>> implemented. So we shouldn't consider 'it will get us closer to read
>> hooks' as a
>> motivation.
>>
>>
> I agree. I can't see why you'd need read hooks except for implemnting
> ACLs, anyway. :-)
For some sort of statistics collection perhaps?
Or you could implement notifications:
if echo $REMOTE_HOST|grep sco.com$; then
echo "Watch out for impending lawsuits!" | mail lawyers@localhost
fi
;-)
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking design (was Re: svn commit: r9885 - trunk/notes)
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>On Wed, 2004-05-26 at 02:46, brane@tigris.org wrote:
>
>
>>+ [How about depth-0 directory locks? The use-case is to protect
>>+ dir props only; useful since those are not merged. --brane]
>>
>>
>
>So, before we go wild with directory locks and depth indicators,
>remember that locks don't interact well with our operational model.
>We're going to run into corner cases like: I lock a file in a working
>directory, make a copy of it, and then unlock it in one of the working
>copies; the other one erroneously believes it holds a lock.
>
>
That's no worse than breaking the lock any other way.
>Because of that mismatch, we're probably best off keeping locks simple
>("protect unmergeably files"), and not imagining new uses for them like
>release branches (which are better handled through acls) and property
>protection.
>
>
*harrum* I'm not "inventing" new uses for locks. I'm simply telling you
how I know they're being used. For example, the decision between using
locks or ACLs for restricting access to a release/integration branch
depends on your process, and there are a multitude of those, all equally
valid. I've spent the last three months modifying ACLs instead of using
locks to block access to the release branch where locks would serve
better, because the tool in question doesn't _have_ directory locks. I
hated every minute of it.
(Before you ask, yes, I did try to get the process changed -- and the
tool replaced -- was actually hired to do so. Hollow laugh.)
>> read and write -- because then we'd open the door to
>> implementing 'read hooks'.)
>>
>>
>
>As an aside, I talked to Ben about this, and I think it's based on a
>poorly-conceived and vague plan of how read hooks might be implemented.
>So we shouldn't consider 'it will get us closer to read hooks' as a
>motivation.
>
>
I agree. I can't see why you'd need read hooks except for implemnting
ACLs, anyway. :-)
>>+ [Looking at this again, I find there's one big problem with using
>>+ the repos layer for this. It means the lock table has to be
>>+ exposed through the FS API.
>>
>>
>I have no idea what you mean. here.
>
>
I mean the lookup table should be part of the FS, of course.
>> How should this be implemented? As a separate BDB table managed by
>> libsvn_repos? That would certainly scale, but then it might create
>>- NFS problems, etc. Another idea is to use an XML file (parsed once
>>+ NFS problems, etc.
>>+
>>+ [Huh? What NFS problems would it create that the repository doesn't
>>+ already have? Well, really. --brane]
>>
>>
>
>So, Ben was theorizing that libsvn_repos could, without the help of
>libsvn_fs_base, open a BDB table and use it. That's of course totally
>unacceptable; we have two fully functioning FS back ends now, and one of
>them isn't hamstrung by Berkeley BD's limitations.
>
>
Exactly. The lookup table should be part of the FS implementation. :-)
>>+ -- useful info in an in-company team. Also a note, commit-log
>>+ template if you will, which could be used to describe the
>>+ reason for the lock to other users. So not only 'who' and
>>+ 'where', but also 'why'.
>>
>>
>
>People may find this cumbersome; I don't think other version control
>systems generally have it.
>
They do.
>I'm not opposed to it unless (deep breath)
>asking for a lock rationale is not the default unless specified by the
>file's svn:lock-required property.
>
>
Yes, yes! We do agree sometimes. Good. :-)
>>+ [Um. Only the lock owner (and an admin, yes) should be able to
>>+ remove a lock. Therefore a lock token should be required by
>>+ default. You could overroide that with "svn unlock --force".
>>+ Then after we add ACLs, there will also be a 'break locks'
>>+ global privilege -- brane]
>>
>>
>
>Why a global privilege? Why not a local one?
>
>
Oh, that's related to the nature of ACL processing. In the ACL itself,
you can say, "anyone can break locks in this tree"; but in the global
privilege assignment you can say, "*this* user may never break locks".
The privilege restriction overrides ACL permissions. It's sort of a mask
on the ACLs.
(Use case? "Anonymous" user with read-only access. You don't want to
have to add the read-only restriction to each and every ACL you create.
Instead, you restrict the set of access privileges that apply to the user.)
>>+ Now if you _really_ need it, you can do "svn lock --force" to
>>+ steal the existing lock. Again, later on, the ACL can tell you
>>+ if a) you can steal locks at all, and b) you can steal other
>>+ people's, not just your own. -- brane]
>>
>>
>
>I was thinking you'd do "svn unlock --force" followed by "svn lock", but
>that's a bikeshed. No need to have two levels of ACLs, really; stealing
>or cancelling your own locks is not an access control issue, and should
>always succeed.
>
>
I guess. I'm still refining the ACL privilege list and semantics.
>>+ ... I suggest the update... should include lock tokens...
>>
>>
>
>
>
>>+ Oh by the way, all of this implies that the server never
>>+ transmits the lock GUID to anyone once the lock token has been
>>+ sent to the owner after an "svn lock", otherwise you open the
>>+ door to lock spoofing -- _not_ a good idea! --brane]
>>
>>
>
>These things seem to contradict each other, so I think I misunderstood
>the first part.
>
>
Yes, I wasn't quite clear. When the client sends a "current state" tree
to the server, it should include any lock tokens it finds in the working
copy. There can be only one of those per path, so the server can reply,
"the lock on *this* path is stale" without having to send the lock token
back to the client, or any client.
Perhaps there's an even easier way; since an "svn st -u" would list
locked files anyway, the client can notice that the lock is gone simply
by the fact that it's not marked as locked in the status/update reply.
Doesn't even have to send lock tokens to the server except on commit or
unlock.
In effect, the server generates a lock GUID and sends the token to the
client _once_, at "svn lock". The client can send lock tokens to the
server at any time.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Path lookup table (was: Re: Locking design (was Re: svn commit: r9885 - trunk/notes))
Posted by Alon Ziv <al...@nolaviz.org>.
On Friday 28 May 2004 09:51, Branko Čibej wrote:
> [...]
> the structure of the index would have look like this:
>
> (dir-id, name, [txn-id]) -> info
>
> [...]
>
> The info contains the bits and pieces attached to the path:
>
> * lock object, ACL, unversioned prop,... for this entry
> * If the entry represents a directory:
> o the dir-id of this directory, used by the next level of lookup
> o a flag indicating whether the lock/acl/prop/... is inheritable
> o maybe a flag if a lock exists anywhere _beneath_ this directory
>
This is very similar to a structure I've been thinking about lately -- used to
store copy source information. In fact, the only difference is that my vesion
used a revision number instead of txn-id (as I want to be able to access them
sequentially).
The method for using this information is just to add a copy-to row for every
copy ever made. When computing the response to a log request, we would also
merge the copy-to information of the directories along the path to the
requested node with the actual changes in the node.
So, we can consider copy-source access as another possible use/benefit of this
table... Thus implementing another oft-requested feature.
Of course, I'm ignoring the fs_fs implementation right now; so far, I haven't
thought of any efficient representation for this information in plain files
(not to mention safety guarantees and the like).
-az
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking design (was Re: svn commit: r9885 - trunk/notes)
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>(Apologies to everyone for the length. Many points of disagreement
>here.)
>
>
(Which is good, we'll at least have a good chance of getting it right
the first time.)
>>I've explained this before. Both ACLs and locks need a path-based lookup
>>table that supports tree-based inheritance. The idea is to use _one_
>>table for both, and a single lookup overhead for both, not reinvent the
>>wheel yet a third time.
>>
>>
>
>(1) Well, if we don't do directory locks, we certainly don't need
>tree-based inheritance for locking.
>
>(2) If we do directory locks, we still don't really need tree-based
>inheritance for locking. We just have to look up the changed
>directories as well as the changed files in the lock table.
>
>(3) We need to maintain history on ACLs, but not on locks. In some ACL
>designs, an ACL change might constitute a commit, whereas a lock or
>unlock pretty much necessarily does not constitute a commit.
>
>(4) ACLs are potentially more numerous and need to be checked in more
>places than locks, but do not change as often.
>
>
I'll start an ACL design thread soonish, and I'll explain my reasons for
wanting to have a common infrastructure in another thread, too.
>(I've asked what happens if a file is deleted when a lock is held on it,
>and got the answer from several people, "well, you can't delete a file
>if you don't hold the lock." Which doesn't really answer my question;
>what happens if you delete the file while you do hold the lock?)
>
>
That depends on whether you restrict locks to apply only to existing
objects or not. For example, most byte-range locking implementations I
know will let you lock a range of bytes beyond the physical end of the
file. This is useful for some forms of IPC, but the main reason to do so
is because it makes the range-lock implementation simpler and much faster.
In the same way, you could decide to allow the SVN user to lock a path
that's not been added to the repository yet, for example, to "reserve" a
file name they're about to add (never mind about the WC-side
implementation problems for now). Let's call this a B-type lock, and the
strictly targeted kind an A-type lock.
Now to your question. For the sake of argument, let's assume that locks
are implemented in libsvn_repos, not libsvn_fs -- it makes the range of
possibilities more interesting.
In this scenario, there are three distinct ways to delete a file: 1.
directly through libsvn_fs, 2. through implicit commit ("svn rm URL"),
or 3. with the help of the working copy ("svn rm path; svn commit").
1. Since libsvn_fs doesn't know about locks, the deletion will succeed.
* with A-type locks: The repository's lock table becomes
inconsistent (ouch!). The WC that owns the lock is confused and
has to treat this as a lock steal.
* with B-type locks: Nothing changes, the lock lives on.
2. Not having a working copy, you can't attach a lock token to "svn rm
URL". Therefore the delete fails.
3. This scenario has two subcases:
3.1 Using a normal commit, the lock is destroyed as part of the commit.
3.2 Using "svn commit --keep-locks"
* with A-type locks: What happens depends on the exact semantics of
the "--keep-locks" switch. Again, there are two choices:
o The commit always destroys the lock, and "--keep-locks"
forces an atomic "commit+lock". Since the file on longer
exists after the commit, the "lock" part will fail,
therefore the whole commit will fail.
o The commit itself doesn't touch the locks table if
--keep-locks is set. The commit will succeed, but the locks
table won't get updated. The result is the same sort of
inconsistency as in case 1.
* with B-type locks: Nothing changes, the lock lives on
If we use A-type locks -- note the "if" because this discussion hasn't
touched on these alternatives yet -- then based on this analysis, two
things become apparent:
* If locking is in libsvn_repos, case 3. implies that this layer has
to play a part in ensuring repository consistency on failed
commits. The maintenance of the filesystem's transactional
guarantees starts creeping from libsvn_fs to libsvn_repos. Hm.
* If locking is in libsvn_fs, case 1. never happens.
If we use B-type locks, locking can be handled by libsvn_repos just
fine, at the cost of complicating working-copy maintenance.
>>I've spent the last three months modifying ACLs instead of using locks
>>to block access to the release branch where locks would serve better,
>>
>>
>
>Why would locks have served better?
>
>
This particular tool (name omitted to protect the guilty, initials are
V.S.S.) doesn't have the concept of a wildcard user ID ("everyone"), so
to lock a directory, I had to modify the ACL for _every_ user of the
system, except the build manager. It would have been so much easier, not
to mention more logical (semantics do matter, IMHO), if the build
manager could have just locked the tree.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Path lookup table (was: Re: Locking design (was Re: svn commit: r9885 - trunk/notes))
Posted by "C. Michael Pilato" <cm...@collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> I think it's important to answer these questions before we look at a
> table of this nature as a future direction for FS directory lookups. I
> suspect the original FS designers did consider using a separate DB
> association for each directory entry, and decided it would be too
> inefficient.
Please don't give us that much credit.
The original FS schema had the directory entries as a massive skel
(like they are today) embedded within the NODE-REVISION skel (in the
nodes table). (That was back when file contents were also stored in
the NODE-REVISIONs, too.) When we realized how stupid that was, we
came up with the representations/strings tables, and moved the
contents items into those tables. Nobody had given much thought to
the efficiency of directory lookups in the skel system -- the idea was
to make things as simple as possible. Additionally, we thought
deltificaton would earn space saving on directory entries lists, which
tend to be quite compressible. But since the un-deltification costs
too much in time, we turned off deltification of directory entries
lists -- so we didn't even get the space savings we'd hoped for.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Path lookup table
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sun, 2004-05-30 at 17:08, Branko Čibej wrote:
> >Actually, I think there is a big question. Unlike a regular filesystem,
> >in Subversion almost all FS usage involves iterating over whole
> >directories.
> How? That doesn't fit.
Checkout, update, switch, diff, status. They all work by grabbing
entire directories out of the repositories, reporting the files that
have changed, pruning off the subdirs that haven't, and recursing into
the remaining subdirs. You won't improve the speed of these operations
with a path lookup table; in fact, if the path lookup table is your only
representation of directories, you'll slow them down dramatically (only
by a constant factor, of course, but a big one).
Commits are different. But the big, time-consuming commits are imports,
which involve repeated operations on a single directory. We're not very
efficient at doing that right now (in BDB, that is; FSFS is quite speedy
because of the directory-plus-changes representation of directories
within transactions), but we don't need a path lookup table in order to
get O(n) performance for n adds to a directory.
The only case where I can imagine a path lookup table really helping is
when you're doing something like serving a web site of out of svn, and
you have a bunch of big directories, and client accesses to those
directories are pretty random. That's pretty marginal.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Path lookup table
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>On Sun, 2004-05-30 at 16:38, Branko Čibej wrote:
>
>
>>I think that there's no question about using anything _except_ a table
>>for directory lookups.
>>
>>
>
>Actually, I think there is a big question. Unlike a regular filesystem,
>in Subversion almost all FS usage involves iterating over whole
>directories.
>
How? That doesn't fit.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Path lookup table
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sun, 2004-05-30 at 16:38, Branko Čibej wrote:
> I think that there's no question about using anything _except_ a table
> for directory lookups.
Actually, I think there is a big question. Unlike a regular filesystem,
in Subversion almost all FS usage involves iterating over whole
directories. With appropriate caching, that's very efficient with our
current representation.
> The only issue is optimizing the representation of directory changes.
I haven't the foggiest how we could make progress on this issue.
> I think we need experience with such a table before we can finalize
> any kind of design, that's why I'm proposing to start this transition
> and experience-gathering now.
As you've pointed out before, the ACL and lock tables are expected to be
sparsely populated, and they won't undergo changes in the same manner as
directories. Moreover, neither behaves like directories from a
versioning point of view (locks aren't versioned at all, and ACLs don't
become immutable). So what experience is to be gained here?
A better way to gain experience is to create a new branch (or new FS
module, although that would require a lot of symbol renaming), add the
path lookup table there, and run some performance benchmarks with
real-world data. That has nothing to do with locks and ACLs, of course.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Path lookup table
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>On Fri, 2004-05-28 at 02:51, Branko Čibej wrote:
>
>
>> (dir-id, name, [txn-id]) -> info
>>
>>
>
>[...]
>
>
>>You'll notice that I didn't spend too much time worrying about how this
>>design scales from locks/acls -- which are expected to be fairly
>>"sparse" in the tree -- to a full-blown directory index. There are some
>>tricky questions to answer; for example, I'm still not sure how to avoid
>>having to write a zillion index entries every time a directory changes,
>>either directly or through bubble-up; or how to keep the constant-time
>>nature of directory copies. It might be possible to even avoid
>>"physical" bubble-up completely. Anyway, these ruminations need a lot of
>>evolving first.
>>
>>
>
>I think it's important to answer these questions before we look at a
>table of this nature as a future direction for FS directory lookups. I
>suspect the original FS designers did consider using a separate DB
>association for each directory entry, and decided it would be too
>inefficient.
>
>
I think that there's no question about using anything _except_ a table
for directory lookups. The only issue is optimizing the representation
of directory changes. I think we need experience with such a table
before we can finalize any kind of design, that's why I'm proposing to
start this transition and experience-gathering now.
I admit that my point of view is very (B)DB-centric, so my arguments
don't necessarily hold for FSFS -- for all I know, directory
representation may already be optimal there, so adding a path lookup
table wouldn't bring so much benefit.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Path lookup table (was: Re: Locking design (was Re: svn
commit: r9885 - trunk/notes))
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2004-05-28 at 02:51, Branko Čibej wrote:
> (dir-id, name, [txn-id]) -> info
[...]
> You'll notice that I didn't spend too much time worrying about how this
> design scales from locks/acls -- which are expected to be fairly
> "sparse" in the tree -- to a full-blown directory index. There are some
> tricky questions to answer; for example, I'm still not sure how to avoid
> having to write a zillion index entries every time a directory changes,
> either directly or through bubble-up; or how to keep the constant-time
> nature of directory copies. It might be possible to even avoid
> "physical" bubble-up completely. Anyway, these ruminations need a lot of
> evolving first.
I think it's important to answer these questions before we look at a
table of this nature as a future direction for FS directory lookups. I
suspect the original FS designers did consider using a separate DB
association for each directory entry, and decided it would be too
inefficient.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Path lookup table (was: Re: Locking design (was Re: svn
commit: r9885 - trunk/notes))
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2004-05-28 at 11:06, Travis P wrote:
> On May 28, 2004, at 1:51 AM, Branko Čibej wrote:
>
> > BDB supports variable-length keys, but table-based databases (which we
> > want to support in future) are notoriously cranky about rejecting
> > such, and they're not very efficient in BDB, either. So the structure
> > of the index would have look like this:
> >
> > (dir-id, name, [txn-id]) -> info
>
> I'm not sure what you mean by cranky.
Well, it doesn't matter. There's a more important reason why we can't
have a lookup table by full pathname: it isn't compatible with O(1)
directory copies.
(We could have a *cache* table indexed by full path, as long as the
cache is populated in a lazy fashion and is of fixed size. Even then,
directory copies could be perceived as having a non-O(1) performance
impact because of their impact on the cache. Easier to avoid having any
DB tables indexed by full path.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Path lookup table (was: Re: Locking design (was Re: svn commit: r9885 - trunk/notes))
Posted by Travis P <sv...@castle.fastmail.fm>.
On May 28, 2004, at 1:51 AM, Branko Čibej wrote:
> BDB supports variable-length keys, but table-based databases (which we
> want to support in future) are notoriously cranky about rejecting
> such, and they're not very efficient in BDB, either. So the structure
> of the index would have look like this:
>
> (dir-id, name, [txn-id]) -> info
I'm not sure what you mean by cranky. I'm most familiar with
PosgreSQL. I believe most DBs support variable length text-type
fields. I know PosgreSQL does, and I'd be surprised if DB2, Oracle,
MySQL didn't. From the docs: "In addition, PostgreSQL provides the
'text' type, which stores strings of any length. Although the type
'text' is not in the SQL standard, several other SQL database
management systems have it as well." Such fields can be primary keys.
Given the quality of the query planner, I suggest not writing off
apparent encoding inefficiencies because you might find that backend
efficiencies more than make up for it. (There are also variable-length
binary types available, though I think there is more variation in them
between different SQL databases.)
PostgreSQL also supports multi-column indices, which can be efficiently
used according to this rule: "The query planner can use a multicolumn
index for queries that involve the leftmost column in the index
definition plus any number of columns listed to the right of it,
without a gap." I mention it because it looks like that might be
particularly useful given your tuple there with an optional third
member.
I know this doesn't have any immediate impact as there is no SQL db
backend. I'm just trying to follow along and was surprised by your
comment.
-Travis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Path lookup table (was: Re: Locking design (was Re: svn commit: r9885
- trunk/notes))
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>(Incidentally, repeating yourself over and over again on this point,
>without presenting any new arguments, as you did in
><40...@xbc.nu> in response to Ben, isn't really helping your
>argument.)
>
>
As usual, I keep forgetting people can't read my mind, and I'm drawing
on my experience in implementing "real" filesystems, which is probably
not common... This explanation could get a bit longish.
I'm looking at the lock lookup table as a transition path towards fixing
one of the deficiencies of the current FS schema (at least the
database-backend version), and that's inefficient representation of the
revision/path index.
In a filesystem -- Subversion's FS is no exception -- most operations
can be broken down into two stages: a) resolve the path into a
filesystem object (node revision), and b) do your stuff with that
object. All access checks, symlink translation, etc. happen during the
first phase, which is usually the most time-critical part of any
filesystem implementation.
In the current BDB schema, directory contents are represented as
variable-sized, unsorted list of entries. In order to find a name in the
directory, the FS has to read the whole list and scan it sequentially,
which means that the cost of path lookups is proportional to directory
size in both time and memory. It also means that we have to write a
complete new copy of the entries list if a single entry changes, which
uses up a fair amount of space in the repository.
Incidentally, many "real" filesystems make the same mistake, most
notably older Unix filesystems. Modern FS's (e.g., NTFS, ReiserFS, XFS)
use some sort of ordering/indexing to make each lookup cost O(log N)
time (NTFS and XFS use a B-tree). Another common way to speed up the
first phase is to put all the information needed for the lookup, access
control, etc. into the same index, increasing locality of reference.
NTFS, for example, puts directory entries, ACLs, and even the contents
of small files into a single B-tree.
In the near future, we'll be adding locking and later ACLs to
Subversion. Both features require a path->object lookup. Assuming we
have directory locks, both require a cheap way to propagate inherited
values. Another feature that's on our list somewhere are unversioned
properties, perhaps even unversioned files(!). All of these could use a
single path-based lookup index. My vision is to slowly evolve this index
until the point where, by 2.0, it can replace the current directory
entries list.
Of course, life wouldn't be interesting if this index could be a simple
path->info mapping. BDB supports variable-length keys, but table-based
databases (which we want to support in future) are notoriously cranky
about rejecting such, and they're not very efficient in BDB, either. So
the structure of the index would have look like this:
(dir-id, name, [txn-id]) -> info
The txn-id is needed for ACLs, for example, because the same path can
have different ACLs in different revisions. The lookup would take a
reference txn id (e.g., resolved from a revision number) and do a "find
first smaller than" type of key search. HEAD would have to be
represented by a magic value; locks are always in HEAD.
The dir-id is a unique directory identifier that sets the context for
the name. We may be able to use a (node-id, copy-id) pair for that; I
haven't thought through all the ramifications. If not, we'll have to
generate a unique directory ID for this index, which is not so nice.
The info contains the bits and pieces attached to the path:
* lock object, ACL, unversioned prop,... for this entry
* If the entry represents a directory:
o the dir-id of this directory, used by the next level of lookup
o a flag indicating whether the lock/acl/prop/... is inheritable
o maybe a flag if a lock exists anywhere _beneath_ this directory
The last item could be an optimisation for recursive directory locking:
if this flag is set, then a recursive lock on the directory would
conflict with an existing lock somewhere beneath it (yes, even if you
own the lock). Maintaining this flag is a bit tricky, but probably
cheaper than scanning the whole subtree for possible lock conflicts. It
might require a few tweaks in the structure of the index to get an
optimal implementation, though.
You'll notice that I didn't spend too much time worrying about how this
design scales from locks/acls -- which are expected to be fairly
"sparse" in the tree -- to a full-blown directory index. There are some
tricky questions to answer; for example, I'm still not sure how to avoid
having to write a zillion index entries every time a directory changes,
either directly or through bubble-up; or how to keep the constant-time
nature of directory copies. It might be possible to even avoid
"physical" bubble-up completely. Anyway, these ruminations need a lot of
evolving first.
There. I've put my brane on display. Hope you enjoy mucking through it. :-)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking design (was Re: svn commit: r9885 - trunk/notes)
Posted by Greg Hudson <gh...@MIT.EDU>.
(Apologies to everyone for the length. Many points of disagreement
here.)
On Wed, 2004-05-26 at 19:11, Branko Čibej wrote:
> >Write to a tmpfile, then move it.
> And add yet another level of file locking for multiprocess
> serialization. Why reinvent the wheel if we've already invented it
> _twice_ -- once using BDB, and once using FSFS?
Inter-process locking isn't such a tremendous wheel that we can only
locate functionality in the FS layer if it needs locking. We also have
locking in the wc layer, for instance.
In this case, if we use a flat file listing of locks, interprocess
serialization flows naturally from atomic replacement from a temporary
file and exclusive opening of that temporary file. If we use a
directory tree of locks, interprocess serialization flows naturally from
exclusive opening of the lock files.
> >Presumably svn_repos_fs_commit_txn(), will read/parse the locks-file
> >every time it is invoked. So it happens exactly once per commit.
> Oh fine. lock;parse;precheck;merge txn;update
> locks;write;fsync;unlock;ouch, someone did hot backup in between...
Where did all this complexity come from? There's no need to lock the
locks table before reading it. There's no need (I believe) to update
the locks table after committing the transaction.
> I've explained this before. Both ACLs and locks need a path-based lookup
> table that supports tree-based inheritance. The idea is to use _one_
> table for both, and a single lookup overhead for both, not reinvent the
> wheel yet a third time.
(1) Well, if we don't do directory locks, we certainly don't need
tree-based inheritance for locking.
(2) If we do directory locks, we still don't really need tree-based
inheritance for locking. We just have to look up the changed
directories as well as the changed files in the lock table.
(3) We need to maintain history on ACLs, but not on locks. In some ACL
designs, an ACL change might constitute a commit, whereas a lock or
unlock pretty much necessarily does not constitute a commit.
(4) ACLs are potentially more numerous and need to be checked in more
places than locks, but do not change as often.
> [On a related note, I'm beginning to wonder why we have a separate
> filesystem and repository layer.
Think of the filesystem layer as being something close to a
transactional filesystem implementation, and the repository layer as
being the server end of a version control system layered on top of that.
By separating out hooks, configuration, and potentially locks, an FS
back end can focus on just being a good transactional filesystem.
> Taking stuff out of the filesystem and putting it in the repos to keep
> the filesystem "clean" is weird, because the definition of "clean" seems
> to shift with the wind (for example, I suggested implementing revprop
> indexes in the repos layer, and ghudson objected. Then I suggested
> implementing locks in the FS, and ghudson objected... :-)
How does my opposition to adding two features to the FS layer constitute
"shifting with the wind?"
> Initially, the separation was supposed to be: FS features into the FS,
> repository features in repos. User identification is a repository
> feature. Hooks are a borderline case. Locks, ACLs and such are
> definitely FS features in my book, because they interact with versioning
> semantics. Anything that requires a path and/or version-based lookup is
> a prime candidate for the FS layer.]
That's a valid viewpoint. Certainly, permissions and locking are both
parts of native filesystems.
I suggested putting locks in the repository layer specifically because
they *don't* seem to interact with versioning semantics very much in our
current conception of them. They aren't versioned in and of themselves
(you can lock a file and unlock a file without making a commit, and
there's no record that you did anything except perhaps in server logs),
they only apply to the head, and if a commit is made which changes a
locked file, the lock remains.
(I've asked what happens if a file is deleted when a lock is held on it,
and got the answer from several people, "well, you can't delete a file
if you don't hold the lock." Which doesn't really answer my question;
what happens if you delete the file while you do hold the lock?)
> The "where" is a note for the users, just like the "why", and does not
> imply that the repository needs to keep track of working copies.
I'm aware that's how you meant it. But even if it's only communicated
to users, I don't want the repository keeping track of working copies in
any way. Where a working copy lives is a client-specific implementation
detail.
Keeping track of where the working copy is that locked a file opens the
door to wanting the server to be able to unreliably answer questions
like "where are the checkouts for this part of the repository" and
"where did the commits come from to this part of the repository." Sure,
someone could conceivably want that information, but it's not what we
do.
> >>If the user wants to manually unset the svn:lock-required
> >>property in order to evade a lock, that's akin to rebuilding the svn
> >>client to ignore it. We can't stop them, so there's no point in making
> >>it harder at the expense of increased user-visible complexity.
> It's this anarchistic tendency again... Let me put it this way. We, and
> many others, are using subversion in an environment where developers can
> be trusted to do the right thing. In such an environment, the
> free-for-all-by-default principle is valid. Now, in many corporate
> environments, you /can't/ trust the developers to DTRT (or the managers
> don't /want/ to), and therefore this has to be a repo admin's decision.
> Will you entertain the idea that we at least _allow_ changing this
> property to be restricted? Or do we want to lock svn out of this
> "market" by default?
Please be more specific. What are you trying to accomplish with this
restriction? If I unset the svn:lock-required property in my working
copy, it's not like that lets me commit a change to the file when
someone else is holding the lock. (If you don't want to let me change
the svn:lock-required property on the server, that sounds like an
argument for property-specific ACLs, not an argument for a complicated
server policy applying specifically to the svn:lock-required property.)
> There's also the issue of default behaviour. It's reasonable to require
> locking for binary files but not for text files by default, and to let
> people change this default -- again in a server config file. Elsewhere I
> suggested a mime-type-based decision, for example.
Once again, rather than implement complicated rules which apply
specifically to locking, we should be looking into general mechanisms
for automatically setting up properties. (Like auto-props, but more
useful.)
Switching over to <40...@xbc.nu>:
>> We're going to run into corner cases like: I lock a file in a working
>> directory, make a copy of it, and then unlock it in one of the
>> working copies; the other one erroneously believes it holds a lock.
> That's no worse than breaking the lock any other way.
It is worse. The user has carried out only supported actions (lock a
file, copy a working copy, unlock a file) and is receiving non-ideal
behavior (the second working copy does not alert the user that editing
the file is a potential waste of time). It's not the end of the world;
it's just an illustration that without server control over working
copies, you can never do a particularly good implementation of exclusive
locks.
> I'm not "inventing" new uses for locks. I'm simply telling you how I
> know they're being used.
Well, from my point of view, it's requirements creep. We embarked on
this mission because users were telling us they have MS Word files or
graphic design files which can't be merged, and they want help
protecting themselves against wasting time on unmergeable edits. Nobody
mentioned anything about locking branches.
Directory locks seem like they introduce more corner case, are more
complicated from the user point of view, and will be harder to
implement, while providing functionality for use cases which are better
served by ACLs.
> I've spent the last three months modifying ACLs instead of using locks
> to block access to the release branch where locks would serve better,
Why would locks have served better?
>>>+ [Looking at this again, I find there's one big problem with using
>>>+ the repos layer for this. It means the lock table has to be
>>>+ exposed through the FS API.
>> I have no idea what you mean. here.
> I mean the lookup table should be part of the FS, of course.
I'm sorry, I can't connect the dots. It looked like you were trying to
make a specific argument that the lookup table should be part of the
FS. But I can't make any sense of your specific argument, and when I
ask you what it means, you simply repeat your conclusion.
>> So, Ben was theorizing that libsvn_repos could, without the help of
>> libsvn_fs_base, open a BDB table and use it. That's of course
>> totally unacceptable; we have two fully functioning FS back ends now,
>> and one of them isn't hamstrung by Berkeley BD's limitations.
> Exactly. The lookup table should be part of the FS implementation. :-)
That's only one of the acceptable alternatives.
(Incidentally, repeating yourself over and over again on this point,
without presenting any new arguments, as you did in
<40...@xbc.nu> in response to Ben, isn't really helping your
argument.)
[In regards to lock rationales:]
>> People may find this cumbersome; I don't think other version control
>> systems generally have it.
> They do.
Conceded. I was thinking of RCS, CVS, and (though I'm not familiar with
it and thus could be wrong about it) SourceSafe.
>> Why a global privilege? Why not a local one?
> Oh, that's related to the nature of ACL processing.
I think global ACL restrictions are as much of a trap as global
variables are in programs--they seem attractive until you suddenly have
a need for them to have different values in different contexts. But
since this thread is about locking and since we have no published ACL
design plan, that discussion doesn't really belong in this thread.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking design (was Re: svn commit: r9885 - trunk/notes)
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
>> With no transaction-based consistency protection?
>>
>>
>
>Write to a tmpfile, then move it.
>
>
And add yet another level of file locking for multiprocess
serialization. Why reinvent the wheel if we've already invented it
_twice_ -- once using BDB, and once using FSFS?
>>>+ Will you let the admin edit the lock file behind a running
>>>+ server's back?
>>>
>>>
>
>Presumably svn_repos_fs_commit_txn(), will read/parse the locks-file
>every time it is invoked. So it happens exactly once per commit.
>
>
Oh fine. lock;parse;precheck;merge txn;update
locks;write;fsync;unlock;ouch, someone did hot backup in between...
Sounds suspiciously like something database transactions are designed to
handle. Or rather, like something the FS implementations already handle.
>> And more to the point, will you take the penalty
>>
>>
>>>+ of keeping the whole lookup table in memory after we add ACL
>>>+ lookup to it and suddenly find that 50000 ACLS are no small
>>>+ thing? *shudder* -- brane]
>>>
>>>
>>Who says we're oging to put ACLs into the lockfile? I'm okay with doing
>>this if it happens to work, but I'm not okay with loading down the
>>locking design with the ACL system's requirements.
>>
>>
>
>Yes, why are ACLs related to locks? We certainly don't want to design a
>locking system that *hampers* a future ACL system, but I don't want to
>intermingle the two efforts unless Branko starts getting very specific
>about ACL design.
>
>
I've explained this before. Both ACLs and locks need a path-based lookup
table that supports tree-based inheritance. The idea is to use _one_
table for both, and a single lookup overhead for both, not reinvent the
wheel yet a third time.
[On a related note, I'm beginning to wonder why we have a separate
filesystem and repository layer. Taking stuff out of the filesystem and
putting it in the repos to keep the filesystem "clean" is weird, because
the definition of "clean" seems to shift with the wind (for example, I
suggested implementing revprop indexes in the repos layer, and ghudson
objected. Then I suggested implementing locks in the FS, and ghudson
objected... :-) And we keep duplicating APIs all over the place because
of this dichotomy. And arguing about where core FS features such as ACLs
and locking should go.
Initially, the separation was supposed to be: FS features into the FS,
repository features in repos. User identification is a repository
feature. Hooks are a borderline case. Locks, ACLs and such are
definitely FS features in my book, because they interact with versioning
semantics. Anything that requires a path and/or version-based lookup is
a prime candidate for the FS layer.]
>>>+ [+2. Also think about optinally adding the client name and local
>>>+ path to the locked file to the token (not only 'who', but 'where')
>>>
>>>
>>Ick. Repository doesn't keep track of working copies. That arrow only
>>goes one way. Otherwise moving working copies around becomes
>>inadvisable.
>>
>>
>Agreed.
>
>
/me bangs head against wall in despair
The "where" is a note for the users, just like the "why", and does not
imply that the repository needs to keep track of working copies. If you
enable sending location info as part of the lock token (not on by
default, of course), and then move your working copy, well, that's your
problem, but the repos won't care.
We're attaching way too much importance on this "WCs can be moved"
mini-feature and using it as an argument against features that cover use
cases where moving WCs is _not_ common. I'm talking specifically of a
corporate environment where it's expected that a repos admin can list
all the locks _and_ their owning WCs to, e.g., check compliance to some
checkin policy.
Also re "lock notes": I _have_ worked -- still do -- in teams where
setting lock notes is common. We find it eminently useful because a
developer can broadcast her intention to the team. In a slightly
stricter environment (where you integrate change and configuration
management), the system will typically _require_ you to set a lock note;
or rather, will generate it from change management metadata. Etc. etc.
I can hear the "subversion is about replacing CVS for open source
projects" litany coming again...now if you insert "1.0" between the
first and second words, I'll buy it.
>>Ben's idea was that the repository will look at the username to decide
>>if you own the lock. But I don't see the situation quite the same:
>>
>> svn unlock file
>> --> transmit lock token, fail if no lock present with that token
>> svn unlock --force file
>> --> don't transmit token, always succeed if my username owns the
>> lock, possibly succeed (based on ACLs) if someone else owns the
>> lock
>>
>This sounds fine to me.
>
>
Can't argue with this, I suggested it. :-)
>>[Regarding the svn:lock-required property:]
>>
>>
>>>+ [I suggest that this should be a read-only liveprop whose
>>>+ value is implied by server-side configuration, and can't
>>>+ be modified by the client. This is a repository policy,
>>>+ not a user decision. -- brane]
>>>
>>>
>>So you need admin privileges to set up an unmergeable file? That's
>>dumb. If the user wants to manually unset the svn:lock-required
>>property in order to evade a lock, that's akin to rebuilding the svn
>>client to ignore it. We can't stop them, so there's no point in making
>>it harder at the expense of increased user-visible complexity.
>>
>>
>
>+1. This is crazy.
>
It's this anarchistic tendency again... Let me put it this way. We, and
many others, are using subversion in an environment where developers can
be trusted to do the right thing. In such an environment, the
free-for-all-by-default principle is valid. Now, in many corporate
environments, you /can't/ trust the developers to DTRT (or the managers
don't /want/ to), and therefore this has to be a repo admin's decision.
Will you entertain the idea that we at least _allow_ changing this
property to be restricted? Or do we want to lock svn out of this
"market" by default?
There's also the issue of default behaviour. It's reasonable to require
locking for binary files but not for text files by default, and to let
people change this default -- again in a server config file. Elsewhere I
suggested a mime-type-based decision, for example.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking design (was Re: svn commit: r9885 - trunk/notes)
Posted by Travis P <sv...@castle.fastmail.fm>.
On May 26, 2004, at 2:03 PM, Ben Collins-Sussman wrote:
> You're misunderstanding my phrase "tmpfile". I didn't mean "something
> in /tmp". :-)
Yes, that was the confusion. I am familiar with same-volume moves
having the
guarantee you are looking for. Thanks for the clarification. :-)
-Travis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking design (was Re: svn commit: r9885 - trunk/notes)
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-05-26 at 13:59, Travis P wrote:
>
> Are you imagining a file move to have some sort of atomic guarantee?
Absolutely. Our working copy library depends on this technique all the
time.
>
> Even if /tmp and the repos are both on local storage, if they are on
> separate volumes (a common case)
If the lock-table is just a file, we create 'locktable.UUID.tmp' and
then move it to 'locktable'. It's a rename within the same directory.
You're misunderstanding my phrase "tmpfile". I didn't mean "something
in /tmp". :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking design (was Re: svn commit: r9885 - trunk/notes)
Posted by Travis P <sv...@castle.fastmail.fm>.
On May 26, 2004, at 12:41 PM, Ben Collins-Sussman wrote:
>> With no transaction-based consistency protection?
>
> Write to a tmpfile, then move it.
Are you imagining a file move to have some sort of atomic guarantee?
Even if /tmp and the repos are both on local storage, if they are on
separate volumes (a common case), a move becomes a copy/delete
operation which might have fewer guarantees than you are perhaps
expecting.
Feel free to ignore this if I'm just misunderstanding what you are
saying.
-Travis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking design (was Re: svn commit: r9885 - trunk/notes)
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
>On Wed, 2004-05-26 at 14:56, Greg Hudson wrote:
>
>
>>On Wed, 2004-05-26 at 13:41, Ben Collins-Sussman wrote:
>>
>>
>>>> With no transaction-based consistency protection?
>>>>
>>>>
>>>Write to a tmpfile, then move it.
>>>
>>>
>>It's not *quite* that simple. If you and I are both trying to lock
>>(different) files at the same time, then we could run into a race. (You
>>read, I read, you write, I write, and your lock is omitted.) If the
>>tmpfile always has the same name and is opened with O_EXCL, then one of
>>us will fail to open the tmpfile, which means there would have to be a
>>retry loop.
>>
>>Another non-DB technique would be to have a directory tree of the locked
>>files. That would scale better in some ways and would eliminate the
>>possibility of multiple people interfering with each other by locking
>>different files, but it would mean checking a to-be-committed
>>transaction against the lock table would be slower. (We could probably
>>use directory pruning techniques to make it pretty fast, though.)
>>
>>
>
>So we're faced with two choices here:
>
>1. create a locks-table API in svn_fs.h, have svn_repos.h use it.
>
> - this means one fs backend would use a BDB table, and the other fs
>backend would have to implement the table either using a flat-file or a
>'mirror' of locked repository paths in real filesystem space.
>
>2. create a locks-tabel API in svn_repos.h
>
> - libsvn_repos absolutely cannot depend on BDB, so it means that it
>would need to implement the table either with a flat-file or a mirror of
>locked repos paths in real filesystem space.
>
>Either way, it looks like the "non BDB" option is going to have to be
>implemented, and real energy will be spent making sure it's reasonably
>scalable. Given that, option #2 seems better to me, just because it's
>nice to have shared/factorized code. And if we plan to add other fs
>backends someday (like SQL), this option becomes even more attractive.
>
>
Or the third (correct) choice:
3. Put the lock/unlock APIs into the FS and let the FS implementation
worry about the details of lookup tables and such
/me walks away whistling...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking design (was Re: svn commit: r9885 - trunk/notes)
Posted by Branko Čibej <br...@xbc.nu>.
Mark Phippard wrote:
>By the way, I set the text to wrap at line 80 (it had a default of 70).
>What is the "proper" setting for that value to get the best compatability?
>
>
It's usually around 70.
>> This is not inconcievable at all. Modulo a few details regarding
>>
>>synchronizing the repository configuration files and hooks, there's no
>>reason why this wouldn't work.
>>
>>
>>
>
>But would you agree that if the locks were held in the repository layer,
>as opposed to the file system, that there would be a problem for this sort
>of scenario?
>
I would.
> It seems to me, that if the locks are in the repository
>layer, then they would not be visible to other instances of the Subversion
>server. I guess that perhaps those servers could all be configured to use
>a common filesystem to store the information, but that could lead to other
>problems.
>
>
Yes. Note that unlike, say, hooks or svnserve configuration, which don't
have to be strictly in sync between different repos instances, the locks
table has to be. Incidentally, so does the mod_dav_svn activity database.
We're drifting a bit far afield now. Bottom line is that a lock table
outside the filesystem would make this kind of load balancing much
harder to do, or put in more bottlenecks.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking design (was Re: svn commit: r9885 - trunk/notes)
Posted by Mark Phippard <Ma...@softlanding.com>.
Branko Čibej <br...@xbc.nu> wrote on 05/27/2004 10:13:02 AM:
> Mark Phippard wrote:
>
> [Could you please send plain-text messages to the list? Or at least
> increase the size of the font? I find I need a magnifying glass to read
> your posts...]
Thank you for pointing that out. The messages looked like Plain Text to
me, I didn't realize it was sending HTML with a plain text font. I am
using Lotus Notes and I think I have found the proper setting to fix this.
By the way, I set the text to wrap at line 80 (it had a default of 70).
What is the "proper" setting for that value to get the best compatability?
>
> > I also think that a lot of corporate users will want to see historical
> > information on locks, such as User A locked FileX at this date/time,
> > even if that lock is now long gone.
>
> This audit trail would more properly belong in the changes table. Unlike
> with ACLs, you don't want historic locks to apply if you check out an
> old version.
>
What I meant was that users might want to produce some kind of historical
report for audit purposes that contains this information. Obviously
commits are more important that locks, but some companies want to see
both. I did not mean to imply that this historical information should be
visible to, or used by Subversion itself.
> > 2) It will likely be common for Subversion to be running on a
> > different physical server than the SQL database and accessing the
> > database via Client/Server. Would it be inconceivable that some users
> > might have several Subversion servers, such as a load-balanced Apache
> > setup, all accessing the same SQL backend? I am not sure if the
> > Subversion libraries could even handle that scenario, but if it could,
> > wouldn't holding the locks in the repository layer mean that the locks
> > would be held on those single Subversion servers, instead of the
> > back-end database?
>
> This is not inconcievable at all. Modulo a few details regarding
> synchronizing the repository configuration files and hooks, there's no
> reason why this wouldn't work.
>
But would you agree that if the locks were held in the repository layer,
as opposed to the file system, that there would be a problem for this sort
of scenario? It seems to me, that if the locks are in the repository
layer, then they would not be visible to other instances of the Subversion
server. I guess that perhaps those servers could all be configured to use
a common filesystem to store the information, but that could lead to other
problems.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking design (was Re: svn commit: r9885 - trunk/notes)
Posted by Branko Čibej <br...@xbc.nu>.
Mark Phippard wrote:
[Could you please send plain-text messages to the list? Or at least
increase the size of the font? I find I need a magnifying glass to read
your posts...]
> Ben Collins-Sussman <su...@collab.net> wrote on 05/26/2004 04:59:27 PM:
>
> >
> > So we're faced with two choices here:
> >
> > 1. create a locks-table API in svn_fs.h, have svn_repos.h use it.
> >
> > - this means one fs backend would use a BDB table, and the other fs
> > backend would have to implement the table either using a flat-file or a
> > 'mirror' of locked repository paths in real filesystem space.
> >
> > 2. create a locks-tabel API in svn_repos.h
> >
> > - libsvn_repos absolutely cannot depend on BDB, so it means that it
> > would need to implement the table either with a flat-file or a mirror of
> > locked repos paths in real filesystem space.
> >
> > Either way, it looks like the "non BDB" option is going to have to be
> > implemented, and real energy will be spent making sure it's reasonably
> > scalable. Given that, option #2 seems better to me, just because it's
> > nice to have shared/factorized code. And if we plan to add other fs
> > backends someday (like SQL), this option becomes even more attractive.
> >
>
> I am thinking ahead to a SQL implementation and had a few thoughts on
> this:
>
> 1) SQL implementations are going to tend to be desired by corporate
> users, and those are the same users that are going to want to use
> locks heavily, including for text files. I think that being able to
> see what locks are currently held, and by whom, would be an important
> feature. If this information were in a SQL table(s) that would be
> relatively easy for those users to implement.
Yes, that's another good argument, and I was thinking along the same
lines. If you've shelled out many M€'s for your huge Oracle
infrastructure, and you perhaps paid someone to implement an Oracle
back-end for Subversion, you'll definitely want to keep _everything_ in
the database.
> I also think that a lot of corporate users will want to see historical
> information on locks, such as User A locked FileX at this date/time,
> even if that lock is now long gone.
This audit trail would more properly belong in the changes table. Unlike
with ACLs, you don't want historic locks to apply if you check out an
old version.
> 2) It will likely be common for Subversion to be running on a
> different physical server than the SQL database and accessing the
> database via Client/Server. Would it be inconceivable that some users
> might have several Subversion servers, such as a load-balanced Apache
> setup, all accessing the same SQL backend? I am not sure if the
> Subversion libraries could even handle that scenario, but if it could,
> wouldn't holding the locks in the repository layer mean that the locks
> would be held on those single Subversion servers, instead of the
> back-end database?
This is not inconcievable at all. Modulo a few details regarding
synchronizing the repository configuration files and hooks, there's no
reason why this wouldn't work.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking design (was Re: svn commit: r9885 - trunk/notes)
Posted by Mark Phippard <Ma...@softlanding.com>.
Ben Collins-Sussman <su...@collab.net> wrote on 05/26/2004 04:59:27 PM:
>
> So we're faced with two choices here:
>
> 1. create a locks-table API in svn_fs.h, have svn_repos.h use it.
>
> - this means one fs backend would use a BDB table, and the other fs
> backend would have to implement the table either using a flat-file or a
> 'mirror' of locked repository paths in real filesystem space.
>
> 2. create a locks-tabel API in svn_repos.h
>
> - libsvn_repos absolutely cannot depend on BDB, so it means that it
> would need to implement the table either with a flat-file or a mirror of
> locked repos paths in real filesystem space.
>
> Either way, it looks like the "non BDB" option is going to have to be
> implemented, and real energy will be spent making sure it's reasonably
> scalable. Given that, option #2 seems better to me, just because it's
> nice to have shared/factorized code. And if we plan to add other fs
> backends someday (like SQL), this option becomes even more attractive.
>
I am thinking ahead to a SQL implementation and had a few thoughts on
this:
1) SQL implementations are going to tend to be desired by corporate users,
and those are the same users that are going to want to use locks heavily,
including for text files. I think that being able to see what locks are
currently held, and by whom, would be an important feature. If this
information were in a SQL table(s) that would be relatively easy for those
users to implement.
I also think that a lot of corporate users will want to see historical
information on locks, such as User A locked FileX at this date/time, even
if that lock is now long gone.
2) It will likely be common for Subversion to be running on a different
physical server than the SQL database and accessing the database via
Client/Server. Would it be inconceivable that some users might have
several Subversion servers, such as a load-balanced Apache setup, all
accessing the same SQL backend? I am not sure if the Subversion libraries
could even handle that scenario, but if it could, wouldn't holding the
locks in the repository layer mean that the locks would be held on those
single Subversion servers, instead of the back-end database?
3) I have worked with products that allow you to associate a comment with
a lock, and I personally think that feature can come in handy (we used it
to associate an Issue ID with a checkout). I have worked with other
products, PVCS VM, that do not let you do this when you create a lock and
have missed the feature.
Thanks
Mark
Re: Locking design (was Re: svn commit: r9885 - trunk/notes)
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-05-26 at 14:56, Greg Hudson wrote:
> On Wed, 2004-05-26 at 13:41, Ben Collins-Sussman wrote:
> > > With no transaction-based consistency protection?
> >
> > Write to a tmpfile, then move it.
>
> It's not *quite* that simple. If you and I are both trying to lock
> (different) files at the same time, then we could run into a race. (You
> read, I read, you write, I write, and your lock is omitted.) If the
> tmpfile always has the same name and is opened with O_EXCL, then one of
> us will fail to open the tmpfile, which means there would have to be a
> retry loop.
>
> Another non-DB technique would be to have a directory tree of the locked
> files. That would scale better in some ways and would eliminate the
> possibility of multiple people interfering with each other by locking
> different files, but it would mean checking a to-be-committed
> transaction against the lock table would be slower. (We could probably
> use directory pruning techniques to make it pretty fast, though.)
So we're faced with two choices here:
1. create a locks-table API in svn_fs.h, have svn_repos.h use it.
- this means one fs backend would use a BDB table, and the other fs
backend would have to implement the table either using a flat-file or a
'mirror' of locked repository paths in real filesystem space.
2. create a locks-tabel API in svn_repos.h
- libsvn_repos absolutely cannot depend on BDB, so it means that it
would need to implement the table either with a flat-file or a mirror of
locked repos paths in real filesystem space.
Either way, it looks like the "non BDB" option is going to have to be
implemented, and real energy will be spent making sure it's reasonably
scalable. Given that, option #2 seems better to me, just because it's
nice to have shared/factorized code. And if we plan to add other fs
backends someday (like SQL), this option becomes even more attractive.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking design (was Re: svn commit: r9885 - trunk/notes)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2004-05-26 at 13:41, Ben Collins-Sussman wrote:
> > With no transaction-based consistency protection?
>
> Write to a tmpfile, then move it.
It's not *quite* that simple. If you and I are both trying to lock
(different) files at the same time, then we could run into a race. (You
read, I read, you write, I write, and your lock is omitted.) If the
tmpfile always has the same name and is opened with O_EXCL, then one of
us will fail to open the tmpfile, which means there would have to be a
retry loop.
Another non-DB technique would be to have a directory tree of the locked
files. That would scale better in some ways and would eliminate the
possibility of multiple people interfering with each other by locking
different files, but it would mean checking a to-be-committed
transaction against the lock table would be slower. (We could probably
use directory pruning techniques to make it pretty fast, though.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking design (was Re: svn commit: r9885 - trunk/notes)
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-05-26 at 10:38, Greg Hudson wrote:
> So, before we go wild with directory locks and depth indicators,
> remember that locks don't interact well with our operational model.
> We're going to run into corner cases like: I lock a file in a working
> directory, make a copy of it, and then unlock it in one of the working
> copies; the other one erroneously believes it holds a lock.
>
> Because of that mismatch, we're probably best off keeping locks simple
> ("protect unmergeably files"), and not imagining new uses for them like
> release branches (which are better handled through acls) and property
> protection.
Ouch, that *is* argument against directory-level locks. But I'd like to
temporarily table this issue, and save it for a separate thread.
> A better plan, in my opinion, is to have svn_repos_fs_commit_txn compare
> the changed-path list to the lock table and reject the commit if there
> are any files locked by a different working copy.
+1 from the Chicago folks. For our initial design, this should be the
only place where we check for locked files. See the other mail thread
as to why.
> So, Ben was theorizing that libsvn_repos could, without the help of
> libsvn_fs_base, open a BDB table and use it. That's of course totally
> unacceptable; we have two fully functioning FS back ends now, and one of
> them isn't hamstrung by Berkeley BD's limitations.
Hm, yah, it would be kinda bad to make libsvn_repos unconditionally
depend on BDB.
>
> > + [Please don't even think of anything but a FS-backend-specific
> > + lookup table. Will you rewrite some text file every time a lock
> > + changes?
Why not?
> With no transaction-based consistency protection?
Write to a tmpfile, then move it.
> > + Will you let the admin edit the lock file behind a running
> > + server's back?
Presumably svn_repos_fs_commit_txn(), will read/parse the locks-file
every time it is invoked. So it happens exactly once per commit.
> And more to the point, will you take the penalty
> > + of keeping the whole lookup table in memory after we add ACL
> > + lookup to it and suddenly find that 50000 ACLS are no small
> > + thing? *shudder* -- brane]
>
> Who says we're oging to put ACLs into the lockfile? I'm okay with doing
> this if it happens to work, but I'm not okay with loading down the
> locking design with the ACL system's requirements.
Yes, why are ACLs related to locks? We certainly don't want to design a
locking system that *hampers* a future ACL system, but I don't want to
intermingle the two efforts unless Branko starts getting very specific
about ACL design.
>
> > + [+2. Also think about optinally adding the client name and local
> > + path to the locked file to the token (not only 'who', but 'where')
>
> Ick. Repository doesn't keep track of working copies. That arrow only
> goes one way. Otherwise moving working copies around becomes
> inadvisable.
Agreed.
>
> Ben's idea was that the repository will look at the username to decide
> if you own the lock. But I don't see the situation quite the same:
>
> svn unlock file
> --> transmit lock token, fail if no lock present with that token
> svn unlock --force file
> --> don't transmit token, always succeed if my username owns the
> lock, possibly succeed (based on ACLs) if someone else owns the
> lock
>
This sounds fine to me.
> (If we allow multiple locks on a file, an idea which I consider really
> bizarre, then there are some more corner cases to consider in the second
> case.)
Like the whole 'directory-lock' concept, let's discuss shared locks in a
separate thread.
>
> [Regarding the svn:lock-required property:]
> > + [I suggest that this should be a read-only liveprop whose
> > + value is implied by server-side configuration, and can't
> > + be modified by the client. This is a repository policy,
> > + not a user decision. -- brane]
>
> So you need admin privileges to set up an unmergeable file? That's
> dumb. If the user wants to manually unset the svn:lock-required
> property in order to evade a lock, that's akin to rebuilding the svn
> client to ignore it. We can't stop them, so there's no point in making
> it harder at the expense of increased user-visible complexity.
+1. This is crazy. Users can manually tweak a file's svn:mime-type
property to control whether a client tries to do contextual merging. In
this same exact spirit, users should be able to set a property that
catergorizes a file as "something that needs locking".
(Eventually, when we have server-side config files that are "broadcast"
to clients, admins can use auto-props (or something similar) to set
global policies about which files are lockable.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking design (was Re: svn commit: r9885 - trunk/notes)
Posted by Patrick Dean Rusk <PR...@foliage.com>.
"Greg Hudson" <gh...@MIT.EDU> wrote:
> > + -- useful info in an in-company team. Also a note, commit-log
> > + template if you will, which could be used to describe the
> > + reason for the lock to other users. So not only 'who' and
> > + 'where', but also 'why'.
>
> People may find this cumbersome; I don't think other version control
> systems generally have it.
SourceSafe and PVCS have it. In ClearCase, you check out a file against a
task. So, I'd say it's pretty common in locking version control systems.
That said, I never put anything in the comments, nor have I ever worked on a
team where others did, AFAIK.
If it's not hard to do, it might be a worthwhile feature to counter the
ubiquitous "our old VCS allowed us to do that" objection that would
inevitably arise.
Patrick Rusk
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org