On 6/25/07, David Glasser <glasser@mit.edu> wrote:
> The essential question in my view is: Is the ability to edit a patch
> before applying it with "svn patch" valuable?
>
> In my opinion, not particularly so; I think the choice between patches
> you can edit but can only apply with "patch" (and lose everything but
> text changes) and patches you can only edit after you apply them (but
> keeps metadata) is perfectly reasonable.
I totally agree with this statement.
> However, one of the last
> times this was brought up, several people did state that the ability
> to edit a patch in a text editor before applying it was incredibly
> important and should not be prevented.
Then I guess people would have to learn svn-protocol first, which I
don't think people want to. It doesn't sound like an option that
people have to know svn-protocol to edit patches. I'm quite sure it
wasn't designed to be human-editable (and even human-readable) and I
hardly see someone having to write tokens, checksums and such things
manually. As glasser suggested, the way better solution to edit after
you apply with 'svn patch' is reasonable and much more intuitive as it
implies using svn commands which people do know about yet. Why should
they have to learn another 'language' (svn protocol) to do the same
thing they can do with a 'language' they already know (svn
subcommands)?
Now I think it's important that people be able to read an svnpatch
patch before they run 'svn patch' against it. And if we go with an
encoded-compressed-chunk, I suggested to write a 'reveal' facility so
that it's easy to read the non-human-readable thing. We lose the
ability to do email code review on-the-fly in this case though. But
do we want to be able to do this with this kind of data -- metadata,
tree, binary changes? If we go with a clear-text chunk format, what
happens with binary bytes?
(I was talking about the chunk here (b), and not the contextual part (a))
Cheers,
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 26 11:52:05 2007