+1 on making "svn patch" take an XML file.
-1 on just providing a gateway to standard patch. We wouldn't be
providing any benefit to users by simply adding the string "svn "
before a command that they'll still have to learn. We have enough
todo reimplementing CVS, we don't need to add `patch' to our list of
tasks. :-)
If we want to make "svn patch" accept standard patch format as well as
our xml format, that's fine, because that's an intuitive unification.
But implementing standard patch without any other functionality (such
as xml) is not a unification, it's a redundancy that will just confuse
people while making more work for us.
-K
Ben Collins-Sussman <sussman@collab.net> writes:
> 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
---------------------------------------------------------------------
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