subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Sperling <s...@elego.de>
Subject Re: Ideas for handling copies/moves in 'svn diff'
Date Wed, 02 Jun 2010 10:22:02 GMT
On Tue, Jun 01, 2010 at 10:04:02PM +0200, Daniel Näslund wrote:
> My main concern was that we didn't use file_added() for all the cases
> involving copies and moves. That was unfortunately far from obvious from
> my last mail. :(

What else do we use, and where?

> Nah, I will need some way to determine if a file was modified after
> copying. I probably will introduce a copy_from field to file_changed().

Hmm... Well, svn diff already knows if a file was modified after copying
or not. How does it do that? Can you do it the same way?

(I think svn diff compares the copy target to some base file but I'm
not sure.)

> _scan_addition() can give us the copyfrom relpath and tell us if the path
> was added or copied. 'svn mv' is currently implemented using a lock and
> doing a svn_wc_copy3() and then svn_wc_delete4(). Thus, we can detect
> copies/moves and we can perform them using wc-ng mechanisms. Or am I
> missing something?

wc-ng also has support for moved-to and copied-to in the DB schema.
Those fields aren't used yet, but eventually they will be used (probably
post-1.7).
 
> A sidetrack: I thought that all editors must implement all
> svn_delta_editor_t funcs, but svn_wc_diff_callbacks4_t only does it for
> a subset, i.e. there's no open_root() or close_edit(). We're calling it
> a diff editor but is it really equal to something like the status
> editor? To me, it feels like a bunch of callbacks created in the same
> spirit as the delta_editor callbacks but not strictly following it's
> conventions.

Not sure. I don't know off-hand how many different editors we got
and what their differences are. You know more than I do.

> I agree with you. I prefer to not change the API more than neccessary.
> On the other hand it has already been revved to 1.7 so some small
> modifications, e.g. possibly adding copyfrom to file_changed() won't be
> too troublesome.

If they help and there's no better way, sure.

> I grepped libsvn_wc without finding any references to copyto. Did you
> mean that the DB schema supports adding those fields in the future?

Yes, that's what I meant.

> In that case, it will be straightforward to detect deletes that is part of
> a move. Will wc-ng 1.7 support copyto information?

As stated above I think it will be introduced post-1.7.

> What I can do at the moment
> ============================
> 1) Create a make_git_header() func inside #ifdef SVN_PATCH_EXPERIMENTAL
> 2) Create a test_git_header() func inside #ifdef SVN_PATCH_EXPERIMENTAL
> 3) Clean up the code paths for file_added() and file_changed().
> 4) While deciding on the best way of detecting copies/moves in the diff
>   code, I can start on the parser in parse-diff.c and write C-tests for
>   it. Will be using #ifdef's here too.

That's a good list to get you started. Once you have those 4 items
done you'll know what comes next.

Happy hacking :)
Stefan

Mime
View raw message