Re: availability of svn_wc_entry->repos

Daniel Rall wrote:
> This is consistent with the data I'm seeing in WC .svn/entries files.
> (There's no reason to duplicate this piece of data.)

Except that all of the keyword management is happening at the lowest level (i.e.
just the file entries are available and it's too late to get anything from the
containing directory).

> Erik Hülsmann pointed out that it would be nice if files inherited the repos
> setting of their parent directory. I have not confirmed whether this is
> occuring for this case in the source code (though take_from_entry() and
> svn_wc__atts_to_entry() in libsvn_wc/entries.c look promising).

Yeah, take_from_entry() already as code there to do this:

   if (! dst->repos)
     dst->repos = src->repos;

but later on in write_entry() we see these comments:

   /*** Now, remove stuff that can be derived through inheritance rules. ***/
...
     /* Avoid writing repository root if that's the same as this_dir. */
...

so now I know why I'm not seeing anything in the .svn/entries file except at the
directory level. If we were going to permit a little duplication, we could just
adjust that code to always print out the repos for files and directories.

However, I also don't think just copying over the parent's entry data is the way
to go in the more general case. The knowledge that the information is being
inherited is just as important as what value is being inherited.

I think the only way this is going to work _well_ is if each file object has a
pointer to the parent directory's entries object, created by the outer loop that
knows about both the directory and the files contained within. This would make
inheriting the directory properties a piece of cake.

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org