On Mon, Jan 22, 2001 at 04:41:06PM -0600, Karl Fogel wrote:
> Greg Hudson <ghudson@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/
Received on Sat Oct 21 14:36:19 2006