On Aug 24, 2006, at 7:11 PM, Talden wrote:
> 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.
sounds great!
unfortunately my binary files may change only slightly in the
application that
generates them, (eg: i move an inverter on a circuit schematic) but the
resulting binary is *very* different to the previous. there's just no
point in
diffing these files, the delta will be close to just sending the new
file over, with
no processing..
i think this is the case for a lot applications, we can't rely on a
small change to a
user data object showing up as a small change to the resulting binary
db that
stores this change.
> 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).
>
it seems like an improvement to me, any developers care to comment?
what are the new diff changes by the way?
thx!
> --
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 25 04:24:01 2006