RE: svn edit

> This seems needlessly complex, and forces *everyone* on the project to

> either use the 'svn edit' feature or not. It's much more elegant to

> make the feature a mode that each user can choose for themselves:

> probably an option to 'svn checkout' which activates this "everything

> is read-only" mode.

>

> You're right that the existing "needs-lock" property sort of reflects

> the behavior we want, but in that case we really *do* want to dictate

> that absolutely every project member play along, since there's a real

> risk of wasted time when people aren't taking strict turns editing a

> binary file. When it comes to a hypothetical 'svn edit' feature,

> though, nobody should need to know whether I'm choosing to work that

> way or not; it should be a private run-time behavior I choose for

> myself.

I agree with your correction, the "svn edit" should be a local thing, not something that gets forced onto all users regardless of whether or not they like it. Additionally, I found a flaw in my previous thinking. The need to walk the tree is not just to inspect the versioned files. "svn status" presently will give you information about unversioned files too.

In order to avoid walking the tree, you need to assume:

1. None of the versioned files have been locally modified, except those which have already been identified.

2. All of the unversioned files (if any) are safe to ignore. The user doesn't want to "svn add" them.

To achieve these assumptions safely, I can see two possible solutions:

Common for both scenarios

1. Let directories in the WC have the ability to take an "ignore-unversioned" flag.

2. Inside of directories which have this flag, "svn status" (and others?) will ignore all unversioned files and directories.

3. It seems possible to let "ignore-unversioned" be implemented as a property inside the repository, or inside the WC, or both. If it's inside the repo, it has the advantage that it can be automatically distributed to all the clients, in organizations that have a standard mode of operations for development. If it's inside the WC, it has the advantage that users can set or unset it without affecting anyone else. The most flexible solution is to implement in both places - Let it be distributed by the repository, and also let it be overridden in the local WC - but this is also the most work to build. The question of implementation - to implement "ignore-unversioned" in WC or in Repo or in both - I leave to whoever. All three ways are adequate solutions.

4. It would probably be worthwhile to implement a new switch "svn status --scan-for-unversioned" for the situation in which a user wants to scan anyway.

Scenario 1 - Performance Motivated Locking

1. At present, I believe "needs-lock" can only be applied to files, not directories. Right? Even if you use auto-props on a directory, it's still just giving the property to all the individual files.

2. Let directories inside the repository have the ability to take a needs-lock property. If a directory has this property, then all its children inherit it too.

3. As a result, "svn status" (and other commands?) can safely assume that no files are modified in the directory or any of its subdirs, except files which were previously locked. No need to scan for modified files.

4. It would probably be worthwhile to implement a new switch "svn status --scan-for-modified" for the situation in which a user wants to scan anyway.

5. If a directory has both "needs-lock" and "ignore-unversioned" then "svn status" (and other commands?) can avoid the need to walk the tree.

Scenario 2 - Performance Motivated Editing

1. Let directories in the WC have the ability to take a "needs-edit" flag.

2. Inside of directories which have this flag, "svn status" (and others?) will assume that none of your versioned files are modified, unless the user previously did "svn edit" on the file.

3. If the user does "svn lock" on a file, it probably implies "svn edit" right? And "svn unlock" implies "svn unedit"?

4. It again seems possible to implement "needs-edit" in either the WC, the repository, or both. There are advantages to each way. The most flexible solution is to implement in both locations, which also requires the most work. All three possibilities are good solutions.

5. Again, it seems like it would do no harm to implement "svn status --scan-for-modified" for the situation in which a user wants to scan anyway. And perhaps "svn status --scan" which is synonymous with "--scan-for-unversioned --scan-for-modified"

6. If a directory has both "needs-edit" and "ignore-unversioned" then "svn status" (and other commands?) can avoid the need to walk the tree.

________________________________
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 17:05:54 CEST