RE: svn edit

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.
Given #1 and #2, we're able to match the performance of perforce. It's pretty cool for free software to beat expensive software at their own game, but it's not very subversion-ish to set needs-lock on all files. We can do even better...

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 e-mail message may contain proprietary, confidential or legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify us immediately at netadmin_at_patni.com and delete this mail.
Received on 2008-10-25 04:31:09 CEST