On Mon, Apr 05, 2010 at 01:41:03PM +0200, Stefan Sperling wrote:
> On Mon, Apr 05, 2010 at 10:02:56AM +0200, Daniel Näslund wrote:
> > Git unidiff format extension to 'svn patch' and 'svn diff'
> > ===========================================================
[..]
> > 2) Add the ability to track renames and copies in libsvn_diff. Probably
> > by using some wc funcs for getting the status. My first assumption
> > was that the svn_wc_diff_callbacks4_t vtable would be revved to allow
> > for copied and moved scenarios once we have editor-v2. But Neels was
> > talking about some bigger rewrite where the diff editor would be
> > dropped. Anyway, as goes for the 'git unidiff format' work, I need
> > some way to detect copies and moves. When I have detection, add the
> > git headers for copies and renames and write tests to confirm the
> > right behavior.
>
> It's a pity that diff is implemented with an editor because it makes
> your task much harder than necessary (you don't have all information
> you need available while the diff is produced piece-by-piece).
>
> Can you think of a way to do this in a simpler fashion?
> I think this could be done simpler by checking all files which
> appear in the diff for 'copyfrom' info.
The question of how to get that information is not easily answered,
given that we allow wc-wc, repos-wc and repos-repos diffs.
neels said on IRC:
[[[
If you're in a wc-wc diff (i.e. "base" -> "working"), you
could get each node's wc-ng status. easy., but in a repos-repos diff or
repos-wc diff, you can't find that stuff unless you a) actively query
the repos for more info or b) use editor v2 to tell that stuff right
away. a) sucks because it duplicates server code on the client side.
]]]
We could decide to only allow git diffs for wc-wc diffs. A decision that
will be hard to motivate for users. But maybe we can get it working for
wc-wc and by the time we're finished, editor-v2 will be too. Though The
'Vision and Roadmap' mail says that editor-v2 will not be scheduled for
release until 1.9. Too bad!
> Let's assume your diff contains files A, B and C:
>
> If you find a single relation A->B,
> if A was deleted: A was moved to B
> if A was not deleted: A was copied to B
> If you find multiple relations A->B, A->C:
> A was copied to B and to C
> maybe A was also deleted
>
> But maybe because of the editorness the receiver (i.e. diff text
> producer) doesn't know about A when dealing with B and vice-versa,
> because it only gets to deal with each of them in isolated function
> calls? Bah. That is really ugly.
> Maybe you can fix this by tweaking the way the diff editor is driven?
> Note though that the same editor is used for merge!
> Or maybe you should rewrite diff this year and then do the
> git-diff-extensions project next year? :)
>
> I like the proposal. The only thing that worries me is that we may
> need to tackle the diff-is-implemented-with-the-merge-editor hack.
> Note that this hack is already biting us elsewhere:
> http://subversion.tigris.org/issues/show_bug.cgi?id=2333#desc12
>
> Maybe we should just bite the bullet and try to re-implement (or "fix")
> diff together before or during gsoc? It certainly would not hurt to
> have this problem solved before adding the git extensions.
Cheers,
Daniel
Received on 2010-04-22 22:26:22 CEST