On Mon, Mar 15, 2010 at 10:33:23AM -0500, Thomas S. Trias wrote:
> Some of our utilities require a list of changed paths for a
> revision, including the sub-paths included in a directory delete /
> replace / copy. For the replace, the ideal situation is to capture
> a set of deletes, replaces, and adds for the descendants.
> We started out using a combination of svn log plus svn diff, but
> found that diff does not include descendants affected by a delete.
> Now we are stuck with svn log, svn diff --summarize for replaces /
> copies, and svn ls (of either path_at_rev - 1 for deletes and
> copyfrom-path_at_copyfrom-rev for copies). We know that the ls and
> diff for copies are probably redundant, but the sanity check is nice
> given the delete case. Needless to say, this has slowed things down
Just to help you better understand the behaviour you are seeing:
The server-side diff and merge code are shared.
During a merge, the information "delete this directory" is sent from
the server to the client, and it's enough (it implies all children
should be deleted in the client's working copy).
During diff, the same server code path is taken, and information about
deleted children is never sent to the client. That's why diff does not
see deletes for children of deleted directories.
I think this is a blatant bug in the diff implementation which should
be fixed. Because of this problem it's not possible to generate diffs
between URLs which can properly be re-applied with a patch tool,
for example. Also, reverse-diffs (where adds should show up as deletes
and vice versa) are not symmetric because of this problem.
> We are using SharpSvn, so I'm fairly certain that the ra_auth
> context persists between calls. If necessary, we can utilize the
> underlying libsvn.
That won't help you, because it's a problem at the server's end.
> Does anyone have any ideas or suggestions on the best way to capture
> this information? Is there an underlying mechanism to return the
> complete graph difference for a revision?
I guess you already have the best possible solution, sorry.
Received on 2010-03-15 16:57:37 CET