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

Re: naming in repos_diff.c

From: Stefan Sperling <stsp_at_elego.de>
Date: Thu, 4 Jun 2009 16:36:51 +0100

On Thu, Jun 04, 2009 at 05:16:11PM +0200, Neels Janosch Hofmeyr wrote:
> Stefan Sperling wrote:
> > But I'd also like to point out (again) that I don't like the fact that
> > "patch" implements its own editor. Because that duplicates a lot of code,
> > and it's hard to maintain in the long term.
>
> Which editor in particular are you referring to?

I was referring to the one in libsvn_client/patch.c actually.
You probably haven't seen that one yet? :)
It might not be directly related to your patch.

> Clarifying: `svn patch' applies a patch file to a working copy, right?

svn patch does more than just that.

It also interprets special "SVNPATCH" blocks inside the unidiff file,
which contain encoded svn protocol commands to describe file additions
and deletions. It uses the editor interface to apply svn protocol
commands encoded in those SVNPATCH blocks. See notes/svnpatch for details.

> So why is there "svnpatch" code in diff?

That I don't really know, because I've not yet looked into how
exactly svnpatch is implemented. But it must have got something
to do with applying SVNPATCH blocks.

> Because `merge' also uses the diff
> framework, or because `svn patch' also needs to do stuff during `svn diff'?

I'd say because merge uses the diff callbacks, yes.
The editor in lisvn_client/patch.c also implements the diff callbacks.

> And, how does all this relate to your comments above? I'm not really
> grokking the interactions yet.
>
> I'm on the ambitious path of trying to disentangle diff from merge in the
> process of enabling arbitrary diffs and introducing editor v2... I'm still
> at the drawing board, so I'm grateful for any details you've got :)

I've already told you all that I know :)

Stefan
Received on 2009-06-04 17:37:37 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.