On 02 Oct 2001 17:43:25 -0500
kfogel@collab.net wrote:
> Mo DeJong <supermo@bayarea.net> writes:
> > It has been a number of weeks since I first posted this patch
> > and the svn_io_run_cmd API has changed, so I figured this would
> > be a good time to post an updated version. This patch adds
> > a framework for the application of patches to a WC. Currently,
> > it just runs `patch -p0 < file` behind the scenes, but the
> > point is to provide a wrapper for application of patches to
> > match the `svn diff` wrapper for generation of patches. As
> > far a I can tell, the result of previous discussion on this
> > topic was that a patch application subcommand was a good thing.
>
> The benefit being that we'd eventually be able to apply `patch++' and
> other formats, such that it would do the "svn add", "svn del", etc for
> you, right? Sounds good.
Yes.
> A question though:
>
> What's the benefit in having this in Subversion before it does more
> than just run `patch', which the user could do anyway? If having this
> subcommand in Subversion now would make it more likely that Subversion
> will soon implement the extended functionality, then it makes sense to
> apply this change right away. But I don't see why it would -- the
> hard part of writing an "svn patch" command is not the framework nor
> the exec'ing of patch, but choosing format[s] and interpreting them in
> a way that is meaningful for Subversion. And it's of no use without
> that extended functionality, since people can just run patch directly.
>
> Subversion should have those extended features. But it should also
> avoid a situation whereby it has, for some long period, just the
> ability to invoke vanilla patch (which is by itself pointless) and no
> more.
>
> I guess what I'm really saying is, would you like to go the whole way
> on this change -- research extended patch formats, document how
> they'll be interpreted, and make Subversion do it? I'm not sure that
> going only part of the way is terribly useful here.
>
> -K
Well, we have to start somewhere. The point here is too seek
agreement on two things. First, that subversion should
support both the generation and application of changes.
Second, that the "patch" subcommand will be the interface
that folks use to access this functionality.
I think we are already agreed that subversion should support
generation of patches that can be traded between developers.
I am making the claim that subversion should support application
of these patches and that a patch subcommand is the right way
to present that functionality to users. For example, I don't
think this is the right way to apply a patch to the WC:
% svn up --xml-file patch.xml
This is the same old "overloaded functionality" problem
that makes CVS hard to learn.
The immediate result of adding this patch is that we can
write up some docs that detail how a user would create
a patch and send it to a developer for incorporation into
a repo. I think that defining how users will actually
do day to day tasks is far more important than working
on the implementation of any one feature. That said, I
am also looking forward to helping out with the
implementation of these commands. I just want to make
sure we clearly define what we want and more importantly
how people will use it before getting started on the
implementation.
cheers
Mo DeJong
P.S.
Your claim that just invoking patch is pointless since
a developer could just run `patch -p0 < patch` is just
not correct. Lots of folks don't know how to use patch,
what the -p0 flags have to do with anything, and why
the shell redirection is needed. It would be far easier
to just point them to a section of the svn docs that
explain how to run `snv patch filename`.
---------------------------------------------------------------------
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:44 2006