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

Future direction for the diff editor

From: Daniel Näslund <daniel_at_longitudo.com>
Date: Tue, 27 Apr 2010 19:02:36 +0200


First, I've been accepted as a GSoC student for the summer of 2010. I'm
really excited and look forward to a summer of coding.

I'm supposed to implement the git unidiff format for 'svn diff' and
'svn patch' and I'll start with the diff side. The git unidiff format
can represent tree changes but unfortunately the diff code in it's
current state makes it hard to detect those tree changes.

What to do?
1) Just allow wc-wc diffs to create diffs with the git format. Use the
   available wc functions to retrieve info on tree changes.
2) Allow diffs involving the repos too by creating special ra functions
   for retrieving the missing information. Something like
3) Start revamping the diff code to not use an editor but instead return
   text-modified and props-modified nodes as detected by the server.
   [1]. In the mail, Greg makes a case for not using an editor in the
   diff code since nothing is modified. As I've understood it, an editor
   is used for almost all repos communication. I see the complexity
   involved in using an editor and I understand that sharing the same
   code for merge and diff has drawbacks. But I'm not seeing how we will
   decrease complexity by not using an editor. We'll still have to
   detect all those tree changes and we'll have to create additional
   code for doing it. If we would just have have to check for
   text-modified and props-modified things would have been different.
4) Wait by the roadside for editor-v2 to be finished. It is supposed to
   automatically detect tree changes.

Has anyone given any more thoughts to how the diff code could be

Unless someone has a clear idea about how to move forward, I'll go with
option 1) and just allow the git format for wc-wc diffs.


[1] http://svn.haxx.se/dev/archive-2009-09/0341.shtml
Received on 2010-04-27 19:03:45 CEST

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