Charles Acknin wrote:
> But, as we're not in a client/server configuration:
> - (b) only uses the svn protocol's Editor Command Set, there's no
> need for
> the Main Command Set nor the Report Command Set
> - a client reads Editor Commands from the patch, i.e. the patch silently
> drives the client's editor
> - the only direction the information takes is from the patch to the
> client
> - svndiff1 is solely used instead of being able to choose between
> svndiff1
> and svndiff0 (e.g. binary-change needs svndiff)
Q: How do you correctly apply an svndiff if you don't have the source
revision where it came from?
A: You can't, because svndiff is based on a block-delta algorithm and
does not contain the necessary context.
Q: How do you correctly apply an svndiff patch offline even if you do
have the source revision?
A: See answer to the previous question.
Q: How do you apply tree modifications if their description consists of
editor commands only?
A: You can't, because editor commands don't carry any context -- they're
like the '+' and '-' lines in a unidiff, without the not-so-unimportant
surrounding bits.
(Q: Why do I have to keep pointing this out? A: Mu! :p )
The only reasonable solution to these problems is, IMHO:
1. Include tree rearrangements with context. Not editor commands, but
-- effectively -- a unidiff of two directory listings. Without
such context, you can't do directory modifications. Then it
suddenly makes sense to make this part of the patch user-readable,
too.
2. For binary files, include the whole file in the patch, and let the
user sort out the conflicts. That's exactly what the Subversion
client does, and for very good reason.
(Sure you can invent contextual patch formats for many binary file
types, and I expect the patch format to be extensible to allow such --
but that's a topic for another few SOCs.)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 4 21:59:13 2007