On 9/26/07, Mark Phippard <markphip@gmail.com> wrote:
> There is a lot of good information and it would be hard for anyone to argue
> that it is not fair and unbiased.
Oh I'm quite biased, but I like to think it's based on experience and
understanding. ;) That, and nobody can pay me enough to lie or shut
up.
> There seems to be a lot of serious momentum towards unifying the WC
> metadata information in the 1.6 or 1.7 time frame. It is exciting to
> think it could deliver those kind of speed improvements.
You could see those speed improvements now -- just set up SVK to
mirror on a large repo, make a local branch and WC, and compare update
or status execution times. It goes even faster when you keep the .svk
cache on a separate disk from the WC. That's how I'm holding out on
the client side, until some SVK "distributed" features start hitting
mainline Subversion. Most of what SVK is doing there is just a
creative use of existing Subversion repository code, on the client
side.
One feature I forgot to mention, that has come up in previous WC
refactoring threads, was a "mark for edit" command. This is similar to
the Perforce "checkout" command -- their "update and get lock"
equivalent, since all Perforce WC files implicitly require locks. This
would allow clients to bypass recursive disk IO status comparisons,
when listing modified files. SVN cleanup commands could be
re-purposed, to update status cache more thoroughly, when necessary.
Perforce commit performance benefits a great deal by having a
"checkout for edit" requirement; but that requirement can really hurt
when you have an editor that overwrites files despite read-only bits,
sometimes without notifying you. For now, I'm trying to write my own
"mark for edit" wrapper scripts, in part using the svn "--targets
edit-list.txt" options, which should eventually extend to all
multi-file svn commands. These scripts might also use any changelists
features provided by future versions.
:) Jred
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 1 05:35:31 2007