RE: svn edit
From: Harvey, Edward <Edward.Harvey_at_patni.com>
Date: Fri, 24 Oct 2008 22:30:31 -0400
Rather than push the direction of "let's be more like perforce," instead let's understand the fundamental concept that makes perforce lightning fast for things like "p4 status" and then apply the knowledge to svn in a svn-ish way.
In perforce, it is implied that all files need lock before they can be edited. Until you use "p4 edit" the file is read-only. "p4 edit" will get a repository lock and make your local copy read-write. Therefore "p4 status" can assume you didn't modify any file other than the ones that you "p4 edit"ed. Therefore "p4 status" is a near-zero cost operation. It just displays to you the list of files that you said you would edit.
The fundamental difference between perforce's locking scheme, versus svn's merging scheme is mergability. Multiple svn users want to simultaneously edit the same files and allow the merge to take place whenever possible. Here's what I suggest:
1. Given: files that have the "needs-lock" property are read-only until you "svn lock" them, after which they are read-write, and locked in the repository. (Just like perforce.)
2. Let "svn status" assume that a file is not locally modified, if it has needs-lock property and hasn't been locked.
3. Let there also be a "needs-edit" property, which behaves similarly to the needs-lock property: The file is read-only until "svn edit." Then the file is read-write, but there is no repository lock. "svn status" will assume a file is not locally modified if it has the needs-edit property and hasn't been "svn edit"ed
4. (For this last point, I think there is already has a solution, yes?) Let both the needs-lock and needs-edit properties have a simple way to assign them globally, to get set automatically on all new files. So the administrator can deploy a needs-lock or needs-edit policy.
Strangely, what I've described above is analogous to filesystem journaling. You perform many small-cost maintenance operations as you go along, so you never incur the large-cost scan. Imagine if you had inotify/FSEvents/FindFirstChangeNotification/etc available to call "svn edit" on every file automatically for you when you "vi" the file. Then the system would be transparently maintaining a list of files that you edited, and you'd never take the performance hit of scanning the tree, and you'd never consider it inconvenient to type "svn edit" because it happens automatically for you.
Whoever commented on my signature - please ignore it. It's tagged on by company policy, and I cannot change it.
This is an archived mail posted to the Subversion Dev mailing list.