On 16 Sep 2001 21:32:02 -0500
Ben Collins-Sussman <firstname.lastname@example.org> wrote:
> Mo DeJong <email@example.com> writes:
> > Here is an initial implementation of the svn patch subcommand that
> > was discussed in my previous post.
> Mo, I see two different needs:
> 1. Subversion users need to be able to trade patches with one
> another, and the patches need to describe not only property
> changes, but tree deltas (e.g. deleting/adding/renaming
> directories as well as files.)
> We already have an XML patch format that does this; the only
> thing that's missing is an enhancement that would allow it to
> contain unidiff data (instead of binary patch data), so it
> becomes human-readable.
> 2. Subversion users need to be able to create patches for CVS or
> other non-Subversion users. An 'svn patch' subcommand should
> be similar to CVS's -- generate standard patch files.
No, no. This command is for application of patches not the generation
of them. A developer would use the diff subcommand to create a
patch and send it to another developer. A second developer would
then use the `svn patch` command to apply the given patch to the WC.
> I'm confused, because it sounds like you're blurring these two cases.
> It sounds like you're trying to push us into extending the current
> standard patch format until it can eventually do everything our XML
> format *already* does. Why reinvent the wheel?
> I agree that Subversion needs to produce ordinary patches; and it
> should make the best use of this format that it can, given the
> limitations. But that's all that needs to be done. If you want nifty
> new patch formats, why don't you help Kevin finish task #1?
I don't care about how the patches are actually implemented.
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. 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.
Of course, all of this does not matter WRT the patch I just posted.
All it does it run `patch -p 0 < foo.patch` when the user runs
`svn patch foo.patch` on the command line. I know it does not
seem like much right now, but it gives us a lot of flexibility down
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Oct 21 14:36:41 2006