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

Re: storing URLs in SVN/

From: Greg Stein <gstein_at_lyra.org>
Date: 2000-12-20 22:53:08 CET

On Wed, Dec 20, 2000 at 01:18:11PM -0600, Karl Fogel wrote:
> Greg Stein <gstein@lyra.org> writes:
> > Um. Let me clarify: it would appear that the subdir's ancestry is stored in
> > the parent's entries file. e.g. it is stored in ./SVN/entries rather than
> > subdir/SVN/entries.
>
> It's not supposed to be that way -- it's supposed to be
> subdir/SVN/entries. What exactly is the part of the code indicating
> otherwise?

Empirical evidence :-)

./SVN/entries has an "ancestor" attribute. There is also an ancestor
attribute in subdir/SVN/entries for the "" entry.

The WC doesn't work if I pass NULL/SVN_INVALID_REVNUM for ancestor_path and
ancestor_revision, so I just have some hard-coded stuff in there. As a
result, there isn't any real "telescoping" going on with the ancestor_path
that I pass in. But that hard-coded string ("### ancestor_path ###") is
stored in both "entries" files.

And since it is hard-coded, it is kind of hard to tell which/how that string
is getting in there. ./SVN/entries looks like:

...
<entry
   name="subsub"
   kind="dir"
   ancestor="### ancestor_path ###/subsub"/>
...

And subsub/SVN/entries has:

...
<entry
   name=""
   kind="dir"
   revision="1"
   ancestor="### ancestor_path ###"/>
...

So you can see it isn't the exact same string simply being copied into two
locations. Not sure what that implies, but something fishy is occurring.

This goes back to whether ancestor_path / ancestor_revision should be passed
during a checkout. I think "no" (but I have to set them today, or the WC
chokes during the checkout). The path is built from NAME, and the revision
should be passed thru something like a set_revision() editor callback.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:17 2006

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.