Re: impending change #2...

Greg Hudson <ghudson@MIT.EDU> writes:

> > * all replace_*() calls now take both base_rev and target_rev
> > arguments, and NO paths at all
>
> > * the add_*() calls now take a base_rev, target_rev, *and*
> > base_path args, so we can support copy history.
>
> Um, target_rev? What happened to
> http://subversion.tigris.org/subversion-dev/current/msg01190.html ?

There's been a lot of discussion here about what to do with updates,
especially between me and Greg Stein, since we're both writing RA
layers.

`Selective updates' is a hard problem.

The system for updates, we think, should work like this:

   * client has a list of specific, non-intersecting targets to update.

   * client hands gives update-editor and target list to RA layer,
     receives a `reporter' vtable.

   * client uses the reporter to describe WC revision numbers (only
     ones which are relevant to the target list)

   * RA layer then drives the update-editor, beginning at the common
     parent of the targets.

       * As the RA layer drives, it will certainly need to call
         replace_dir() many times *without* bumping revision numbers

       * By adding "tgt_rev" to each replace_*() call, we're giving
         the driver the ability to communicate which objects get
         bumped; objects only get bumped if tgt_rev > 0.

I think this system is fundamentally better than the old idea --
whereby the client is the thing that ultimately decides which items to
bump after the update completes.
Received on Sat Oct 21 14:36:21 2006