Greg Stein wrote:
> Julian Foad <julianfoad_at_btopenworld.com> wrote:
> > In WC1, when a WC node is scheduled R+ (replacement with history), the
> > concept of "Base" is being hijacked to provide a place to store the
> > pristine copy of the replacement, and the real base is RENAMED to
> > "Revert Base". That's all wrong: the concept of "the base" should ALWAYS
> > mean "the base that we would revert to".
>
> All wrong: agreed.
>
> But definition: disagree. I believe that BASE should be what we get
> from the server. The *absolute* pristine copy. Nothing can change it
> -- it is always a reflection of the repository. You need to use
> checkout, update, switch, or commit to alter your view of the
> repository.
That's what I meant. (I forgot that the idea of a partial revert, back
to the copy-from source, had been mooted.)
You have to be careful with language like "Nothing can change it":
perhaps say, "It is the view of the repository which can only be changed
by commands such as checkout, update, switch and commit."
> Note that with the concept of BASE, WORKING, and ACTUAL, that the
> revert process for ACTUAL can revert to one of *two* things. You could
> undo local mods against a copy, or you could undo the copy itself. We
> simply do not distinguish in our command line capabilities. (and
> possibly not in our APIs).
>
> > The extra thing being stored in an R+ situation is a pristine copy of
> > the copy-from source. It is not "the base". We stored it as if it were
> > "the base" so that we would not have to change the APIs or the client in
> > order to make the default client's default "diff" command perform a diff
> > against this copy.
>
> Yah. It's all whacked. We'll get better APIs.
>
> > So the new WC should store, for each node:
> >
> > * Base:
> > - repos URL_at_REV
> > - cached text and props (if caching enabled)
> >
> > * Copy-from source (present only on a node scheduled A+/R+):
> > - repos URL_at_REV
> > - cached text and props (if caching enabled)
> >
> >
> > Basically I am saying it does not make sense to use the label "working"
> > for copy-from sources, and we should define:
> >
> > * the "base" tree is the tree that we would revert to;
>
> Well, there are two ways to revert, I'd prefer to stick to "same as
> repos" for BASE, which is basically immutable.
Agreed.
> > * the "copy-from" tree is sparsely populated, not really a "tree" as
> > such but just an (often empty) set of nodes;
>
> Fair enough. But just a name change over the WORKING that I defined?
No, I don't think so. Well, I never really understood the WORKING that
you defined. Sorry :-)
But no, anyway, the word "working" is to me a user-level concept that is
talked about in the book and implied in the syntax and help of "svn"
commands. It means "the stuff that the user is working on".
> > * the "working" tree is what the user works with, using whatever
> > combination of Subversion commands and OS commands the client requires.
> > I think this corresponds to the current 'svn_opt_revision_working'.
>
> I'd stick with ACTUAL for this; I don't see much need to change
> something we're used to.
But ... don't you see that it is what "svn_opt_revision_woprking" refers
to. To me, "actual" is a word you introduced recently to describe
somemething like what I think the well established "working version"
concept has meant to the user; the differences being only in WC-layer
details.
I don't know why we've such different views.
Partly, maybe, ... When you first started defining these and I said
"hold on, there's only two trees we need", I was thinking in terms of
the clientl-level view of the WC, not impl details. (And I ignored the
copy-from source because it seems to me a detail of much less
significance.)
Then I realised that you'd been looking WITHIN the WC layer and making
distinctions between different parts of its implementation, and there,
if we're keeping the basic architecture (tree changes being managed by
Subversion, content changes being made directly on disk by the user) it
is necessary to be able to distinguish these things in APIs internal to
the WC layer.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=987642
Received on 2008-12-19 18:25:34 CET