Mo DeJong <supermo@bayarea.net> writes:
> I am more interested in how the end user is going to go about
> creating and applying patches with subversion. It is one of
> the areas that CVS really punted on and it causes me no
> end of grief in "day to day" work with CVS. The application
> of changes to the WC is no different than the application of
> changes from another branch. By pulling the "application of changes"
> interface into an svn subcommand we free ourselves of a
> lot of baggage.
We are talking about the same thing, then: being able to easily
produce *and* apply patches. And what I'm saying is that Subversion
already does this. Currently, you can commit to an XML-patch file,
and update from an XML-patch file. I sent a demo to this list
recently. It only needs a few tweaks here and there.
The code you submitted still looks useful; if somebody sends me a
'normal' patch, I suppose it's nice to run 'svn patch patchfile'
instead of 'patch -p0 < patchfile'.
All I'm saying is: let's not pursue the path of extending the
standard patch format. That particular problem is already solved. I
was objecting only to your proposal to start throwing svn subcommands
into the standard patch format.
> Also, I am not sure we want to rely on an external diff and external
> patch program in the future. It may become too much of a
> hassle. For example, we are already seeing problems on FreeBSD. We
> may end up just using our own code to create and apply diffs and
> skip the exec's all together. That would no doubt make life easier
> on Windows since it does not include a diff or patch program.
Agreed. Right now, every time you run 'svn up', diff and patch are
being run behind the scenes, so that we get file "merges" for free.
We'd like to internalize this functionality someday, as CVS does.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:41 2006