On Mon, Dec 18, 2000 at 01:50:23PM -0600, Karl Fogel wrote:
> Greg Stein <gstein@lyra.org> writes:
> > When doing a checkout/update, when would ancestor path ever get set? It
> > would seem that the client doesn't care about the ancestory -- that is only
> > important for the client to track when a "svn move" or "svn copy" is
> > performed (and then forgotten during the commit).
>
> I think the client does care, actually.
>
> Consider this freaky update scenario:
>
> 1. Client reports its state to the repository. This
> communicates to the server, either explicitly or implicitly,
> the rev of every file in the portion of the wc being updated.
>
> 2a. Server computes the appropriate diffs to send back, based on
> this state.
>
> 2b. Meanwhile, the version number of something on the client side
> changes. (Maybe another, smaller update got run entirely
> during the state-reporting stage of a larger update.
> Whatever.)
Evil.
> 3. The client receives the diffs from the update that started in
> step 1. But for some file, the received diff is against the
> wrong version. If the client isn't told what version the diff
> is supposed to be against, it can't check that its local copy
> is still at that version.
>
> IOW, since the wc was not locked during a state reporting stage, the
> state reported might be obsolete by the time the diffs come back. We
> need ancestry (rev and path) information to detect this case.
Hrm. I'd say that you need just the revision. (to sanity-check the diff is
against the right revision of the file)
> > Given that the editor interface says the ancestor_revision is ignored when
> > the ancestor_path is NULL, then when/how does the checkout/update process
> > tell the WC what revision a particular file is?
>
> The documentation is simply reiterating that ancestry must always be a
> pair: you need both revision and path. One is meaningless without the
> other.
>
> So, it looks like the ancestry arguments in editor calls must be
> passed when driving an update editor. (Note: the update editor may
> not actually be doing these ancestry checks right now, but at any rate
> it will have to once we're doing state reporting.)
no, it doesn't seem to be doing much with the values at all. Not even the
revision.
> For checkout, the argument is less compelling. I mean, obviously the
> wc has to have all the ancestry data by the time the checkout is done,
> but that's just a matter of getting it for the root dir and using it
> over and over again, extending paths as necessary. It would be nice
> to pass the arguments to the editor calls anyway, but I guess you
> don't have to. (Yeah, having optional arguments like that makes me
> feel funny too, but don't have a better answer. :-) ).
In the checkout case, it appears (again) only the revision is needed.
It seems the path is only important on the commit side of things, as a way
of tracking the ancestry of a change.
It is non-orthogonal (the client doesn't need the path) because the client
is a snapshot of state. It doesn't care *where* it came from. It is only
concerned with changes made to it. (the client uses "svn log" to discover
history information)
[think think think]
We have four "main" editor processes, and in all cases, the revision *must*
be supplied to the editor:
1) report revision status [to determine what must be updated]
- definitely need the revision; don't need the path, though
2) apply updates to the WC
- need the revision so the WC knows what rev is now in the WC
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
4) checkout fresh source from the server
- need the revision so the WC knows what rev is now in the WC
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.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:17 2006