Greg Stein <firstname.lastname@example.org> writes:
> > But you
> > don't, of course -- the target ancestry is implied by the ancestry of
> > the parent in which the target is being replace.
> Well, I'm not quite so sure that I agree... the target's ancestry is *not*
> implied by the parent. Consider the following operation:
> $ svn update some/dir
> [ a time period elapses ]
> $ svn update some/dir/foo.c
> P some/dir/foo.c # this updates foo.c to v7; dir is ???
> Now, let's say that we attempt to copy something over the top of foo.c. If
> we tell the server that we're replacing "foo.c, v6", then the server is
> going to bark at us. It will complain because it doesn't know if you're
> attempting to copy over v6 or v7 of foo.c.
I see what you're saying. I'm not sure this is a problem that needs
to be solved by changing the editor interface, though; I think there
may be enough information there to detect this case anyway.
My apologies for having to defer so many issues till "tomorrow" (two
days I've done that now). There's a lot of other noise going on over
here right now, and technically I don't even work on Wednesdays :-),
so at a certain point I just punt until the next day, heh.
I think we can get all this stuff resolved during the day tomororw,
though, and get back to coding. Ben and I are trying to organize
these various threads into a list of specific issues and tackle them
one by one.
> And a separate topic/point: just what is the version of the directory in the
> above case? I'd think it is somewhere between v6 and v7. Note that it isn't
> v6 because foo.c is at v7. And it isn't v7 because we only fetched foo.c
> (there may be other v7 changes in the directory that we *didn't* fetch).
Yeah, that's probably a meaningless question :-). The directory
records its version as being v6 until you do "update .", but you could
end up with every file in the directory being at some version other
than v6 before that happens.
Received on Sat Oct 21 14:36:17 2006