Re: svn edit

Harvey, Edward wrote:
>> 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.

BTW, I recently found out that there is an `svn status -q' which omits
unversioned items. If that's of any relevance.

>
>
>
> 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.

See above, `svn status -q' vs. `svn status'.
~Neels

>
>
>
> 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.
>