[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Ben Collins-Sussman <sussman_at_newton.collab.net>
Date: 2001-01-20 03:16:12 CET

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

Status Quo:

   These editor functions now take arguments "ancestor_path" and
   "ancestor_revision".

Proposed Change:

   Replace these two arguments with "base_revision" and
   "target_revision" instead within replace_*(), and nothing but a
   "target_revision" in add_*().

Rationale:

   We agreed in a previous discussion (on the dev list) that the
   "ancestor_path" argument is meaningless in these routines; this
   path can be inferred via the sequence of parent dir_batons.

   This leaves only a single "revision" argument left. The problem is
   that the meaning of this argument is unclear.

   Why we need a "target" revision:

       When updating the WC, the RA layer needs to specify the new
       version of the object being created. There's currently no way
       to do this. Both replace_*() and add_*() routines need this
       ability.

   Why we also need a "base" revision for replace_*():

       When updating the WC, the RA layer needs to specify *which*
       object it is trying to replace. This is a problem also
       discussed on the dev list; it's possible that the revision of
       a working copy object might change in the *middle* of a larger
       update, creating the risk of the RA layer applying an incorrect
       patch. There are many ways to solve this via WC locking or
       bookkeeping, but the simplest answer is to have the RA layer
       declare what it's trying to replace and allow the update-editor
       to bail if there's a descrepancy.

       In the commit use-case, the WC declares the "base" revision on
       which it is sending local changes.
Received on Sat Oct 21 14:36:19 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.