Re: svn needs a patch subcommand (Was svn ci/up --xml-file)

Mo DeJong <supermo@bayarea.net> writes:

> 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 agree -- this sounds like good UI design.

> 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.

Then let's just move this functionality to your 'patch' subcommand:

  % svn patch patch.xml

No more confusion, no more overloading.

Similarly,

  % svn diff --xml-file patch.xml

...would create an "extended" XML patch file, instead of just dumping
unidiff data to the screen.

Karl Fogel writes:

> 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.

Once again, I vote -1 on this endeavor. This problem is already
solved. We already have an extended XML patch format; it only needs
a few tweaks for human readability.

And I honestly believe that this solution is *technically* superior to
embedding commands within the standard patch format, too. The XML
format directly maps to our "editor" paradigm of making tree changes,
and it would be a big pain to align the standard patch-format with
this paradigm.

---------------------------------------------------------------------
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