[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: Daniel Näslund <daniel_at_longitudo.com>
Date: Sat, 29 Aug 2009 07:01:08 +0200

On Fri, Aug 28, 2009 at 07:46:30PM -0500, Ben Collins-Sussman 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've been doing some small contributions to the code for a couple of
weeks. It would be fun to help out with something fresh and learn a bit
about the design process when creating a new feature.

With the proper guidance (Bert, stsp?) I would be interrested to take on
this! If it's manageable for a person with my level of knowledge of the
code base and programming skills, it's up to others to judge.


Received on 2009-08-29 07:01:31 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.