[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn_client_patch()

From: SteveKing <steveking_at_gmx.ch>
Date: 2003-04-06 18:16:20 CEST

> > if the patch isn't in text format, you're going to see a large
> > resistance to using it from most open source developers. mailing off
> > a patch to a mailing list works well because one can just glance at it
> > and see what it's doing. if your proposed solution is something
> > opaque (or even just cryptic text like the old xml stuff we had back
> > in the day), it seems like a showstopper to me.
> Yeah, I agree.
> Steve, I'm not sure you know this... but in the very early days of
> Subversion, we didn't have a repository at all. 'svn commit' actually
> wrote out a tree-delta into an XML file, and 'svn update' read and
> applied the XML file to the working copy. Our XML file, was, in
> effect, a tree-aware patch format. Exactly as you descirbe.
> But it contained binary data (svndiff), and wasn't very easy to read.
> There was no way we could inflict our XML DTD as a "standard".
> Ultimately that code got deleted once we had a working repository. :-)

ok, then what about this:
additional to the 'binary' patch the patchfile also includes the output
of svn diff so the user can read it?
The patch file would have on top the diff output and attached a textual
representation of the binary part - like an email with an attachment.
That way the user can still read the patch file, and it will also be
possible for the patch to contain log messages, renames, ...


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 6 18:18:09 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.