Re: Change #2: Modify prototypes of replace_*() and add_*()

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

>    Why we need a "target" revision:

>        When updating the WC, the RA layer needs to specify the new
>        version of the object being created.

Isn't this a constant for a given update operation?

Re: Change #2: Modify prototypes of replace_*() and add_*()

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

Greg Stein <gs...@lyra.org> writes:
> Nope. We decided to pass it to each function to avoid the issues with option
> (1). On balance, we felt that (2) was a cleaner solution. Yes, it is a
> constant, but passing it (rather than stashing it into an editor-global)
> seemed cleaner.

Okay, thanks, that all makes sense to me.  I even remember agreeing to
it now. :-)

-K

Re: Change #2: Modify prototypes of replace_*() and add_*()

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

On Mon, Jan 22, 2001 at 04:41:06PM -0600, Karl Fogel wrote:
> Greg Hudson <gh...@MIT.EDU> writes:
> > >    Why we need a "target" revision:
> > 
> > >        When updating the WC, the RA layer needs to specify the new
> > >        version of the object being created.
> > 
> > Isn't this a constant for a given update operation?
> 
> I also am confused (but possibly misremembering).
> 
> There's no doubt about base_revision being an argument to replace_*().
> It's used to conveniently check that received data is still applicable
> to the target entity.  Although that check could be done entirely via
> local bookkeeping, it's just simpler and more robust to have a
> parameter to compare against.
> 
> As for the target_revision, there were two lines of thinking:
> 
>    1. It's a constant across the entire update, so just mention it at
>       the beginning of the edit and don't make it a parameter to any
>       of the replace_*() or add_*() functions.

At the time the editor is constructed, we may not have the target revision.
In fact, we have to fetch *something* before we get it.

Thus, when the WC asks the RA to do a checkout or update, then how does the
RA notify the WC [update editor] of the target revision, after the RA has
started its work?

a) The construction of the WC update editor is deferred. This is the whole
   "currying" problem. We found that to be ugly.

b) A special editor function is used to set the target revision. But then we
   fall into "how/when/how-often can that be called?"

>    2. Do pass it to each replace_*() or add_*(), because although it's
>       constant across the update right now, things might not always
>       so.

The prime example is an "svn update" for a WC that refers to multiple
repositories. There are two ways to handle this:

a) Construct multiple editors; one for each repository. (this was the
   tentative decision for how to deal with multiple repositories)

b) The target revision is passed for each resource, recognizing that
   crossing repository boundaries will typically mean a different revision.

> Now, I actually had thought we agreed on #1.  But Ben was taking notes

Nope. We decided to pass it to each function to avoid the issues with option
(1). On balance, we felt that (2) was a cleaner solution. Yes, it is a
constant, but passing it (rather than stashing it into an editor-global)
seemed cleaner.

Cheers,
-g

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

Re: Change #2: Modify prototypes of replace_*() and add_*()

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

Greg Hudson <gh...@MIT.EDU> writes:
> >    Why we need a "target" revision:
> 
> >        When updating the WC, the RA layer needs to specify the new
> >        version of the object being created.
> 
> Isn't this a constant for a given update operation?

I also am confused (but possibly misremembering).

There's no doubt about base_revision being an argument to replace_*().
It's used to conveniently check that received data is still applicable
to the target entity.  Although that check could be done entirely via
local bookkeeping, it's just simpler and more robust to have a
parameter to compare against.

As for the target_revision, there were two lines of thinking:

   1. It's a constant across the entire update, so just mention it at
      the beginning of the edit and don't make it a parameter to any
      of the replace_*() or add_*() functions.

   2. Do pass it to each replace_*() or add_*(), because although it's
      constant across the update right now, things might not always
      so.

Now, I actually had thought we agreed on #1.  But Ben was taking notes
and I wasn't, and a *lot* of things were discussed.  What does
everyone else recall from that discussion?  Was there a good argument
against #1 or for #2?

-K