Ancestry arguments for replace functions (was Re: Greg Stein's...)

[Greg Hudson <gh...@MIT.EDU>]

>    We agree that this seems to be the case, and therefore that the
>    ancestor_path argument to replace_file() should go away.  (There
>    may be analogous changes implied by this elsewhere in the editor; I
>    haven't studied that question yet but expect it to be obvious when
>    I do.)

Presumably the ancestry arguments should go away for
replace_directory() as well.

I can make the requisite changes to xml_output.c when the time comes,
assuming I'm around.  If I don't happen to be around, they should be
really simple; just remove the arguments and pass NULL and 0 to
output_addreplace().

Re: Ancestry arguments for replace functions

[Karl Fogel <kf...@galois.collab.net>]

Greg Stein <gs...@lyra.org> writes:
> Why is the ancestor_revision still necessary? Initially, we were saying that
> parameter only has meaning when ancestor_path is present. If you're saying
> it stays, then it also seems to imply that it has meaning outside of the
> presence of ancestor_path.

No, we still need the ancestor_path -- but it is now wholly implied,
through the enclosing parent dir.

We need the ancestory (hence the rev) because the server needs to know
what the diff is against, so it can construct the full text of the new
file.

> I like my set_revision() and copyfrom_* naming better. Much clearer. I have
> no idea on the state/semantics of these ancestor_* things now. Especially if
> you toss one and not the other :-(

How does it feel after the above clarification?

Re: Ancestry arguments for replace functions

[Greg Stein <gs...@lyra.org>]

On Fri, Dec 22, 2000 at 08:01:14AM -0600, Karl Fogel wrote:
> Greg Hudson <gh...@MIT.EDU> writes:
> > >    We agree that this seems to be the case, and therefore that the
> > >    ancestor_path argument to replace_file() should go away.  (There
> > >    may be analogous changes implied by this elsewhere in the editor; I
> > >    haven't studied that question yet but expect it to be obvious when
> > >    I do.)
> > 
> > Presumably the ancestry arguments should go away for
> > replace_directory() as well.
> > 
> > I can make the requisite changes to xml_output.c when the time comes,
> > assuming I'm around.  If I don't happen to be around, they should be
> > really simple; just remove the arguments and pass NULL and 0 to
> > output_addreplace().
> 
> Okay, thanks for the guide.
> 
> (Note we're just talking about ancestor_path -- the ancestor_revision
> is still necessary.)

Why is the ancestor_revision still necessary? Initially, we were saying that
parameter only has meaning when ancestor_path is present. If you're saying
it stays, then it also seems to imply that it has meaning outside of the
presence of ancestor_path.

???

I like my set_revision() and copyfrom_* naming better. Much clearer. I have
no idea on the state/semantics of these ancestor_* things now. Especially if
you toss one and not the other :-(

Cheers,
-g

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

Re: Ancestry arguments for replace functions (was Re: Greg Stein's...)

[Karl Fogel <kf...@galois.collab.net>]

Greg Hudson <gh...@MIT.EDU> writes:
> >    We agree that this seems to be the case, and therefore that the
> >    ancestor_path argument to replace_file() should go away.  (There
> >    may be analogous changes implied by this elsewhere in the editor; I
> >    haven't studied that question yet but expect it to be obvious when
> >    I do.)
> 
> Presumably the ancestry arguments should go away for
> replace_directory() as well.
> 
> I can make the requisite changes to xml_output.c when the time comes,
> assuming I'm around.  If I don't happen to be around, they should be
> really simple; just remove the arguments and pass NULL and 0 to
> output_addreplace().

Okay, thanks for the guide.

(Note we're just talking about ancestor_path -- the ancestor_revision
is still necessary.)