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

Re: svn commit: rev 2386 - trunk/subversion/libsvn_fs

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-07-02 16:41:36 CEST

cmpilato@collab.net writes:

> sussman@tigris.org writes:
>
> > Author: sussman
> > Date: Mon, 01 Jul 2002 17:03:30 -0500
> > New Revision: 2386
> >
> > Modified:
> > trunk/subversion/libsvn_fs/tree.c
> > Log:
> >
> > Fix bug #776:
> > Let the dumper call svn_fs_contents_changed() on any two nodes.
> >
> > * libsvn_fs/tree.c (svn_fs_contents_changed): remove the artifical
> > restriction requiring that we compare two files.
> > svn_fs__things_different() certainly doesn't care; it's just
> > comparing data-keys and prop-keys. Heck, we could compare a file
> > against a dir if we wanted!
>
> This function is listed in include/svn_fs.h under the topic "Files",
> and has the word "contents" in its name. Files have contents.
> Directories do not (in filesystem speak, they have "entries"; the
> generic term for the stuff in files and dirs is "data"). The use of
> svn_fs__things_different under the hood is an implementation detail
> unrelated to the promises made by, and the semantic use of, the
> svn_fs_contents_changed function.

Directories don't have "contents"? Entries aren't contents?

> Please revert this change, and change your calling code to simply ask
> the is-file() question.

You're missing the spirit of the change. The dumper wants to pass any
two nodes to svn_fs__things_different -- two dirs, two files,
whatever. It wants to know if the data keys or prop keys are
different. It does this whenever it writes an add-with-history; it's
trying to decide whether or not to include the added node's contents
in the dumpstream or not, and the only way it can do that is to see if
the source node and copied node have truly changed contents or not.

If you're worried about blurring the meaning of
svn_fs_contents_changed, then I can just write a new public fs
function with a different name that has the exact same implementation.
We need to expose svn_fs__things_different to the public somehow.
Suggestions?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 2 16:46:23 2002

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.