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

Re: computing paths, revision numbers (was: Re: ancestor path / revision)

From: Ben Collins-Sussman <sussman_at_newton.collab.net>
Date: 2000-12-20 20:59:14 CET

Greg Stein <gstein@lyra.org> writes:

> > Sorry, I don't mean to sound like a broken record... either my brain
> > is broken and I'm totally confused, or there's a fundamental
> > misunderstanding here.
>
> I believe one point may be that I'm seeing ancestor_path as optional, and
> only used when a resource has been copied from somewhere else. You're saying
> that if "/foo/bar.c [6]" has been modified, then at commit time, we pass
> "/foo/bar.c", 6 as the ancestor_path/ancestor_revision. If that is true,
> then the ancestor_path value is redundant, and providing the pair gives the
> impression that it has been copied from elsewhere (we would have to compare
> the path against what we're building via the NAME parameters).
> [ I think it should only be used on a copy, rather than being redundant with
> the NAME parameters ]
>
> And yes, the ancestor_path needs to be an absolute URL to work properly.
>
> So... do we have a semantic conflict on the use of ancestor_path? If that is
> true, then we have another discussion :-)

Ohhhhhhhhhhhhhhh.

[think think think]

Yeah.

You're doing a good job of fixing my broken brain. :)

I see what you mean. There's a redundancy. Lemme digest this.
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.