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

Re: [PATCH] dir_delta content check

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2003-11-26 09:19:54 CET

Chia-liang Kao <clkao@clkao.org> writes:

> Revised patch with cmpilato's comments and additional md5 check.
> Avoid dir_delta from calling apply_textdelta that is actually noop
> with ignore_ancestry is on. This makes many things work better in the
> case of two mutually merged branches, since editors now know the
> source and target stream are the same without having to construct the
> fulltext from the noop txdelta. svn diff the two branches will no
> longer show a lot of empty diffs.
> * libsvn_repos/delta.c
> (compare_files): New.
> (delta_files): Use compare_files instead of svn_fs_contents_changed
> with ignore_ancestry is on.

Okay, I've cleaned up your patch (added lots of commentary, and fixed
some style things). And now it has been committed as revision 7852.

Dude. This sped up my test-cases by some 300% !!

So, let me start a theoretical discussion (open to any watching eyes).
I like that this is symmetrical with how commits work -- are there any
reasons why we wouldn't want dir-delta to *always* do this? I mean,
is there ever a time for any update-ish operation (update, switch,
diff, merge, status -u) where it's important to know the difference
between "this thing's contents have changed, but the result is a
no-op" and "this things contents have no changed" ?

Update and switch don't care, because they just do contextual merges
of the textdeltas anyway. Diff and merge certainly don't. Status is
iffy -- we have a field in the status structure for
repos_text_changed. But then again, we also have a
repos_prop_changed(), and it only gets set if there were real diffs in
the properties, not just because the props were touched.

Therefore, I'm seriously tempted to make dir-delta always use this new

NOTE: Before anyone suggests modifying svn_fs_contents_changed() to do
this more careful checking -- don't. The repository dumper code
actually does want to preserve the history of whether edits -- if even
no-ops -- happened on a node's props or contents, so the functionality
provided by svn_fs_props_changed() and svn_fs_contents_changed() must
remain unchanged (though, the API promises need a *serious* overhaul).

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 26 09:21:03 2003

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.