Greg Stein <email@example.com> 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 " 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 :-)
[think think think]
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