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

Re: reducing code bloat by removing svnpatch? (except unidiff)

From: Mark Phippard <markphip_at_gmail.com>
Date: Fri, 28 Aug 2009 21:03:28 -0400

On Aug 28, 2009, at 8:46 PM, Ben Collins-Sussman <sussman_at_red-
bean.com> wrote:

> Comment from the peanut gallery:
> Git has apparently done a fantastic job of 'extending' the standard
> diff/patch format with backward-compatible metadata that modern
> version control systems need. Mercurial has essentially standardized
> around this format as well. (Everyone in the hg world runs 'hg diff
> --git' semi-automatically now, and the --git option may soon become
> the default.) I hear rumors that bzr is now supporting it too
> (kfogel?).
> A long, long time ago we had a mailing list in which different SCM
> people came together to discuss a "universal format for representing
> changesets". The list ended up being a failure, but N years later it
> seems like at least the distributed version control world *has*
> finally standardized on a common format. If we want subversion to
> remain relevant/useful/interoperable for the future, we should
> probably strongly consider rewriting this whole feature to use the new
> defacto standard.
> This is not to trivialize all the work that went in already; but in
> hindsight, it may not be the best overall product strategy. And if
> we're busy questioning whether the existing code is even maintainable,
> all the more reason to consider a fresh start on this problem.


I was going to suggest the same thing for the same reasons. I tried
to find documentation and details on this format but couldn't. Which
is why I did not comment.

ISTR glasser suggested this recently too.

Good thing is that all the unidiff work done recently would be very
relevant for this too.


Received on 2009-08-29 03:05:08 CEST

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.