On 9/30/07, Greg Hudson <ghudson@mit.edu> wrote:
> On Sun, 2007-09-30 at 20:35 -0700, Jared Hardy wrote:
> > One feature I forgot to mention, that has come up in previous WC
> > refactoring threads, was a "mark for edit" command.
>
> Yeah... I think the general consensus is (or would be, if people thought
> about it) that "mark for edit" would produce wonderful speed for
> recursive WC operations, and wouldn't be a hassle when you're using an
> editor with a well-integrated svn mode, but would be a horrible pain in
> the butt when you aren't.
Good point -- Perforce is a good example of being a "horrible pain in
the butt" with editors and file browsers that don't have SCM
integration. That is in part because all files are assumed read-only
until marked otherwise by the WC cache, so changed files run the risk
of getting written over by repo versions. Instead of having a separate
"mark for edit" concept, they combined "checkout" as both update and
get-lock, with their assumption that everything in a WC starts out
untouchable, yet their "locks" are not always exclusive.
My personal need for a "mark for edit", or similar command, is to
avoid local folder recursion. We are stuck with several Win32/NTFS
clients which are butt-pain-slow at such recursion. In our use case,
we would use the edit-list for most update/status/commit commands. For
the few times we don't trust the edit-list, a separate command would
recursively update the edit-list -- very much like a cleanup command.
The point is making recursion the exception, rather than the rule.
Folder recursion is the unavoidable rule in Subversion right now. I
don't think that marking everything that is not on the edit-list with
a read-only bit is necessary. The read-only bit really seems to be a
kludge, to remind the user to "checkout/get-lock" when using editors
that don't have decent SCM integration. Because editors do exist that
ignore read-only bits (or unset-reset them without user intervention),
I think the better solution is an "edit-list correction scanner", that
does the recursion when specifically asked. No matter about the
implementation details -- I simply don't think it's a good idea to
force recursive folder scans on the user every time a command is run
on any folder.
I guess I would be fine with something like consistent use of the
"--targets edit-list.txt -N" options in all multi-file commands
(including status!). Then I could just continue using my custom
wrappers to generate and use the edit-list.txt file. I'm even working
on a method of tweaking Windoze File Explorer, to make my wrapper
script run by default on common production file types. Files will get
"edit marked" any time they are double-clicked. The script in turn
runs the default "Open" action on the file, to keep things easy for
the end user. I'm sure a similar trick could be done with any GUI file
manager, regardless of integration with anything like Tortoise. In
Win32, this trick even works for files that are opened from the
command prompt shell. Even if the user is just viewing files without
changing them, processing the resulting edit-list is still faster than
folder recursion.
:) Jred
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 3 21:02:13 2007