Re: perforce versus subversion

Being able to supply an "svn:diffasnew" (or a hopefully better one)
keyword that instructed the client and the server to treat the file as
a complete replacement diff might perhaps be more straightforward.
This would not be too severe in terms of effort I expect and wouldn't
change anything in the backend storage.

Auto-adding these keywords based on rules for path and mime-type would
make this relatively convenient to use until a more permanent solution
comes along.

It wouldn't resolve issues for people with large slow updating
binaries in their repositories now, but then the approach also
wouldn't prevent a better solution being introduced later (someone did
mention that another diffing approach was on the cards).

--
Talden
On 8/25/06, listman <listman@burble.net> wrote:
>
> it seems that people in denial regarding subversion performance? SVN
> is very slow for certain kinds of repositories, esp those that
> include large binary files. this is a fact and is openly discussed at
> most of the companies i've dealt with. my last 3 companies have seen
> 10-20 min updates in situations, a fresh commit is similiar in
> overhead. My point is that Subversion is great, unless you have large
> binary files in your working env.
>
> the real question is, when are we going to try and resolve the
> redundant diff operations, and even give a switch to turn off the
> diff for certain classes of file. then, maybe we'd get close to
> perforce performance for large binary data.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org