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

On Tue, Dec 19, 2000 at 11:27:11AM -0600, Ben Collins-Sussman wrote:
> Greg Stein <gstein@lyra.org> writes:
>...
> > 1) report revision status [to determine what must be updated]
> > - definitely need the revision; don't need the path, though
>
> Again, how can you decouple the path from the revision? If the
> working copy reports "I have version 7 of glub/foo.c", how does the
> repository know which node it's talking about? Don't we need to
> specify all resources using absolute filesystem paths?

I'm building the path from the NAME passed into the calls.

The above statement is referring to the ancestor_path parameter, which I
don't need. And since that represents a "copy" from somewhere else, and we
may not have done that, then it will be NULL (and the ancestor_revision will
be INVALID / ignored).

The point is that I need the path built from NAME, and the revision number
from the entries file.

ancestor_path/ancestor_revision are not needed.

(note that reporting doesn't really need to report the copied items; we're
 looking for an update, so those don't apply)

> > 2) apply updates to the WC
> > - need the revision so the WC knows what rev is now in the WC
>
> It also needs the absolute filesystem path.

It is building that from the NAME parameter.

When I apply some kind of change to the WC, I need to say, "this change is
for <THIS> revision." The WC can then assert that it *does* have that
revision and whether the update can be applied properly.

I also need to tell the revision, "after you apply this update, you will be
revision REV." i.e. after applying the 6/7 diff, the WC will be v7.

So... during an update, we have *two* revision numbers of interest: what is
expected to be in the WC, and what the final revision number will be.

> > 3) commit WC changes to the server
> > - need the path/revision pair to describe ancestry from a move/copy
> > - need the revision to specify what a diff was built against
> > - add file/dir: revision is N/A
>
> Need path/revison pair to describe *any* local changes, not just
> move/copy. (When adding a file or dir, the the working copy reports
> the resource's revision as "0", btw.)

The path is based on building from the NAME parameter. I'm referring to the
ancestor_path/ancestor_revision pair. Those are only used if the thing in
the WC has been copied from elsewhere.

If I don't specify that pair, then I have some changes against a specific
revision. That needs to be stated somehow.

> > 4) checkout fresh source from the server
> > - need the revision so the WC knows what rev is now in the WC
>
> And it needs to know the absolute filesytem path, too.

Again: building from the NAME parameter.

So how do we tell the WC, "you are revision 7" ?

> > How about if we upgrade revision to generally "required", and the "start
> > from scratch" case allows a NULL/INVALID_REVNUM pair if there is no
> > ancestor? And the path element is typically NULL.
>
> 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 :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/