Paul Libbrecht wrote:
> Le 26 juil. 04, à 16:32, C. Michael Pilato a écrit :
>
>>> Did I understand wrongly ? How hard would it be to modify
>>> Subversion so that the patch-format is pluggeable.
>>
>> Why would you actually want this? I think some real use-cases --
>> including where Subversion is failing you now -- would help out here.
>
>
> One use case is to be able to base on a more descriptive
> representation of change to allow, for example:
> - source respecting updates (e.g. respecting an "own" identation scheme)
> - more explicit merging, including the ability to show merging within
> a user-interface: (the person has added this element and you have
> added this element as well, what should we do ? Currently, such
> conflict resolution is done in the source!)
> - more explicit merging may mean a better computation of the update
> operations' commutativity, hence less frequent conflicts.
> - more explicit merging may also mean a better "management of change"
> where a tool may analyze the incoming changes and warn on the impact
> of things that depend on that (or do the same at commit time, so that
> you know whose content you may impact by publishing such a change)
>
> Hope that gives some light, I do think there's more but these are a
> few important ones, I think.
But none of these should touch the way the server and client exchange
data. I think there's a misconception at work here again. You can
already plug in your own diff on the client, using the diff-cmd and
diff3-cmd config options (granted, it would take a bit of work to make
their behaviour depend on the type of file), and you can maintain
invariants (e.g., enforce an indentation shceme) on the server in
pre-commit hooks. But changing the _delta_ algorithm -- the one that
determines how the server and client communicate changes, and how
changes are stored in the repository -- doesn't make sense. Yes, you
could get slightly more efficient storage for certain kinds of files,
but you wouldn't achieve any of the goals you mention above.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 27 06:54:24 2004