Nicolás Lichtmaier wrote:
>>> Just as Subversion took the best of CVS concepts and created a better
>>> version control system, we should take this format and enhance it so
>>> that it can serve Subversion needs. Those new needs are three:
>>>
>>> * The ability of describe tree modifications (renames, deletions,
>>> etc.),
>>>
>>
>> This is more complicated than it looks, if you insist on compatibility
>> with current diff/patch. Diff is file-based, whereas tree modifications
>> are not.
>>
>> For example, patches are separable: you can take a patch which contains
>> diffs of several files, split it apart, and apply each file's hunk
>> separately. When you add tree-modification metadata to such patches,
>> this is (in general) no longer true; and to be safe, a patch program
>> that accepts such an enhanced diff format should be able to warn you
>> that you're missing some tree modifications when you apply a patch.
>>
>> I certainly don't know how to do this by simply extending, e.g.,
>> unidiff.
>>
>> [...]
>>
>
> Sorry, perhaps I wasn't clear. I'm not proposing a new format
> compatible with unidiff. I'm in fact arguing for the opposite. A new
> format which is "inspired" by unidiff goals, achievements and looks,
> but completely incompatible. I would even change the "---" and "+++"
> markers so as to make it clear that the new format is not compatible,
> although it might look similar. The rationale for not even trying to
> be partially compatible is not providing something that sometimes
> works and sometimes it doesn't.
Oh, all right. That makes all the difference. :)
[...]
>>> * The patch should convey all the meaning implied in a 'svn merge'
>>> operation that is considered reasonable. A patch should be like
>>> tearing the merge action into two steps, i.e.: 'diff + patch = merge'.
>>>
>>
>> diff + patch != merge
>>
>> I don't know how that misconception came about, but merge typically
>> looks at three sources, not two (and note that there's a prototype 4-way
>> merge in Subversion's source tree).
>>
>
> Perhaps there's something I'm not understaning. As I see it there the
> 3 ways are:
>
> 1) The common ancestor (which is the "from" revision in the diff)
> 2) The proposed end result
> 3) The current local source. All of them are present in a normal diff
> operation.
No, diff looks at two files. plain 'svn diff" looks at the the file in
the working copy, and at what that file looked like when it was last
updated from the repository, e.g., it's most recent "ancestor".
Merge, on the other hand, looks at three files: The file you're merging
from, the file you're merging to, and the common ancestor of these two
files. You could say that 'diff3 + patch == merge', but 'diff' and
'diff3' don't produce the same results.
And a good thing, too, otherwise you'd get way too many extraneous
conflicts during merges.
[...]
>>
>> If you don't have inexact patch, then the diff/patch thing becomes
>> pretty much useless for code exchange (/and/ for merging).
>>
>
> The same as regular Subversion merges. Binary merges are aborted and
> left as an exercise for the user. That is not making Subversion
> merging useless, so I don't see why it would render a patch merging
> useles...
I was of course referring to binary diff/patch/merge. Since you can't do
inexact binary patch/merge in general, it's not useful for code
exchange, so you might as well not bother with a generic binary diff format.
By all means make your patch format extensible in such a way that binary
diffs (or deltas, a different beast) can be added, but I don't believe
actually defining and implementing something like that is feasible for a
SoC project.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 1 12:40:22 2007