Le 26 juil. 04, à 16:32, C. Michael Pilato a écrit :
>> We have an XML-diff and would like to put it to use inside such a tool
>> as subversion. The latter should provide us the storage and transport
>> mechanism, being agnostic of the data of the diffs and
>> updates... Maybe I should call this the "patch" format.
> Subversion is already agnostic -- it treats all files as binary when
> transferring changes between repos and client.
"changes", that's what we want to affect.
>> 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.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 27 00:08:36 2004