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

storing the absolute path in the WC (was: Re: ancestor path / revision)

From: Greg Stein <gstein_at_lyra.org>
Date: 2000-12-20 06:42:35 CET

On Tue, Dec 19, 2000 at 01:08:47PM -0600, Karl Fogel wrote:
> Branko =?ISO-8859-2?Q?=C8ibej?= <brane@xbc.nu> writes:
> > > I guess I don't see the problem. Can you give a scenario?
> >
> >
> > $ svn checkout http://foo/bar
> > A bar
> > A bar/baz
> > A bar/baz/bzz
> > A bar/baz/bzz/a.c
> >
> > $ cd bar/baz/bzz
> > $ svn copy a.c b.c
> >
> > If "bar/baz/bzz" doesn't know the whole path, you have to climb up the
> > working copy until you find a directory that does. And that means you
> > can't copy a subtree of the working copy and use it somewhere else,
> > because it isn't self-contained.
> >
> > On the other hand, I may be plain stupid and am missing something obvious.
>
> Well, I don't know about "obvious", but you should be comforted to
> know that every directory knows its own absolute ancestry path (see
> the dir's own entry in bar/baz/bzz/SVN/entries). That's where it gets
> the information; it doesn't have to walk up any trees.

That information isn't being stored properly on a checkout.

It appears that the WC is relying on the ancestor_path, rather than
composing the absolute value from the repository URL and the NAME parameters
passed during the walk.

This goes back to Karl's earlier note: there appear to be two ways or
expectations on where this absolute URL comes from:

  1) checkout URL + composition with the NAME parameter (what I thought was
     happening)
or
  2) the checkout process passes this information as ancestor_path (and the
     NAME stuff is redundant)

[ and we have revision number issues that I've mentioned: how are revision
  numbers specified in (1); for (2), it is using ancestor_revision ]

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.