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

Re: Adapting "client diff" to compare a WC dir against a repos dir

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 02 Sep 2008 19:56:28 +0100

On Tue, 2008-09-02 at 14:25 -0400, Karl Fogel wrote:
> Julian Foad <julianfoad_at_btopenworld.com> writes:
> > Does this attempt look like a sane way to determine whether a WC
> > directory tree is the same as a repos directory tree?
> >
> > This is for the tree-conflict case where a merge wants to delete a dir,
> > but first wants to know whether this WC dir is identical to the
> > merge-left source dir.
> >
> > I'm trying again to write a comparison function,
> > libsvn_client/merge.c:dirs_same_p(). This attempt uses some of the guts
> > of repos_wc_diff() from libsvn_client/diff.c. Note that diff "summarize"
> > would be doing much the same as this - retrieving minimal info on the
> > differences - but is not implemented for repos:WC diffs. It looks like I
> > can do it this way. The sheer number of access batons and callbacks and
> > editors and things needed to set up this comparison is a bit daunting
> > for me, but if it sounds reasonable I will plug in all the bits I can
> > find and see if it works.

> Why do some of the _file_() functions take mimetype arguments? Won't
> you have to compare all the properties anyway, not just the mime type?
>
> Oh, I see, because they're implementing svn_wc_diff_callbacks3_t APIs.
> Are you intending to ignore some of the arguments?

In those callbacks3_t functions, I'm intending to ignore ALL of the
arguments and just set a flag to say "Aha! There must be differences
because one of these diff callbacks has been called".

> Does "equal" in this context mean that all the versioned objects are
> exactly the same as in the repository, or does it mean that not only all
> the versioned objects are exactly the same as in the repository but also
> there are no unversioned objects?

Only versioned objects are to be considered.

> I'm really wondering if it isn't time for us to implement a standard
> tree-checksum method, that can be used on both the repository and client
> side. Something like this (very rough draft):
>
> /* Set @a *checksum to a checksum for the tree (dir or file) rooted
> * at @a path in @a repos. The checksum will be the same for all
> * trees that have the same contents, regardless of what repository
> * they are in or what sequence of edits led the tree to be in that
> * state.
> *
> * @note Entries in a directory are not ordered; only their names and
> * targets matter.
> */
> svn_error_t *
> svn_repos_tree_checksum(*checksum, repos, path);
>
> Similarly, there would be a function like this:
>
> svn_error_t *
> svn_wc_tree_checksum(*checksum, repos, path,
> svn_boolean_t consider_unversioned_objects);
>
> Then we could just compare the checksums.
>
> Thoughts?

Yes, that sort of thing is a very real option. Both the client-side and
server-side implementations could be very efficient, looking up a
previously cached answer.

Thanks for the thoughts.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-02 20:56:47 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.