Re: svn diff, svn merge, and vendor branches (long)

Ben Collins-Sussman wrote:

>Greg Hudson <ghudson@MIT.EDU> writes:
>
>
>
>>I wonder if the right answer isn't to just punt the (distance == -1)
>>check from delta_dirs(). Is there a real penalty for expressing a file
>>as a delta against something unrelated?
>>
>>
>
>Well, I was pondering this question too. We use dir_delta all over
>the place... svn diff, svn merge, svn up, svn switch. Is there ever a
>time where we definitely *should* see a delete+add instead of a patch?
>I think cmpilato had an example.
>
>

There is obviously a big difference betweena modification and a delete+add.

"svn diff" should, as far as possible, attempt to document repository
changes. For the moment, let's ignore the fact that there isn't a
symmetric "svn patch" comand that could actually recreate those
differences. Assuming "svn patch" existed, a "svn diff" + "svn patch"
sequence should ideally do the same thing as a "svn merge" with
appropriate arguments

Now, whether "svn diff" could represent a delete+add in a more compact
way than it does now is debatable, but I don't think that the current
diff format can rescribe the complete removal of a file other than as a
removal of its contents.

So I see two solutions: the short term is to change (_not_ fix!) "svn
diff" to produce output that "makes sense" the way Eric wants. The
not-so-short-term solution is to leave the "svn diff" semantics alone --
or even make it behave more like svn merge -- and start thinking about
the diff output instead. Specifically: What are the changes necessary to
the "standard" -- whatever that means -- diff output, to make it
possible to represent rename, move, and delete/add new file?

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org