You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Kamesh Jayachandran <ka...@collab.net> on 2006/08/03 09:10:25 UTC

Re: svn commit: r20953 - branches/merge-tracking/subversion/libsvn_client

dlr@tigris.org wrote:
> Author: dlr
> Date: Thu Aug  3 12:44:22 2006
> New Revision: 20953
>
> Modified:
>    branches/merge-tracking/subversion/libsvn_client/diff.c
>
> Log:
> On the merge-tracking branch: Incremental progress towards
> notification handling.  Not yet fully functional, but not expected to
> break any previously working tests, either.
>
> * subversion/libsvn_client/diff.c
>   (notification_receiver_baton_t): A new data type containing the
>    state gathered while receiving path notifications.
>
>   (notification_receiver): A new svn_wc_notify_func2_t implementation
>    to wrap the one passed on to the editor by the merge routines.
>
>   (determine_merges_performed): A new function to create merge info
>    describing the merge of RANGE into our target, without including
>    merge info for skips or conflicts from NOTIFY_B.  Doesn't yet
>    handle conflicts, nor is completely correct for skips.
>
>   (update_wc_merge_info): Rewrite this function to handle empty merge
>    info, and re-purpose it to be called once per merge of an
>    incremental revision range (as opposed to once after all revision
>    ranges have been merged).  While somewhat less efficient, this is
>    seems to be necessary to properly handle WC notifications.
>
>   (do_merge, do_single_file_merge): Use notification_receiver_baton_t
>    and notification_receiver() wrappers when performing a merge to
>    keep track of which paths are skipped/conflicted.  Take those paths
>    into account when updating the WC's merge info (by way of
>    determine_merges_performed()).
>
>
> Modified: branches/merge-tracking/subversion/libsvn_client/diff.c
> URL: http://svn.collab.net/viewvc/svn/branches/merge-tracking/subversion/libsvn_client/diff.c?pathrev=20953&r1=20952&r2=20953
> ==============================================================================
> --- branches/merge-tracking/subversion/libsvn_client/diff.c	(original)
> +++ branches/merge-tracking/subversion/libsvn_client/diff.c	Thu Aug  3 12:44:22 2006
> @@ -1861,55 +1861,169 @@
>    return SVN_NO_ERROR;
>  }
>  
> -/* Calculate the new merge info for REL_PATH based on the merge info
> -   for TARGET_WCPATH and RANGES, and record it in the WC at
> -   TARGET_WCPATH. */
> +/* Contains any state collected while receiving path notifications. */
> +typedef struct
> +{
> +  /* The wrapped callback and baton. */
> +  svn_wc_notify_func2_t wrapped_func;
> +  void *wrapped_baton;
> +
> +  /* The list of any skipped paths, which should be examined and
> +     cleared after each invocation of the callback. */
> +  apr_array_header_t *skipped_paths;
> +
> +  /* Pool used in notification_receiver() to avoid the iteration
> +     sub-pool which is passed in, then subsequently destroyed. */
> +  apr_pool_t *pool;
> +} notification_receiver_baton_t;
> +
> +/* Our svn_wc_notify_func2_t wrapper.*/
> +static void
> +notification_receiver(void *baton, const svn_wc_notify_t *notify,
> +                      apr_pool_t *pool)
> +{
> +  notification_receiver_baton_t *notify_b = baton;
> +
> +  if (notify->action == svn_wc_notify_skip)
> +    {
> +      if (notify_b->skipped_paths == NULL)
> +        notify_b->skipped_paths = apr_array_make(notify_b->pool, 1,
> +                                                 sizeof(char *));
> +
> +      APR_ARRAY_PUSH(notify_b->skipped_paths, const char *) =
> +        apr_pstrdup(notify_b->pool, notify->path);
> +    }
> +
> +  if (notify->content_state == svn_wc_notify_state_conflicted)
> +    {
> +      /* ### We might be able to use the entries cache instead. */
> +    }
> +
> +  if (notify_b->wrapped_func)
> +    (*notify_b->wrapped_func)(notify_b->wrapped_baton, notify, pool);
> +}
> +
> +/* Create merge info describing the merge of RANGE into our target,
> +   without including merge info for skips or conflicts from
> +   NOTIFY_B. */
> +static svn_error_t *
> +determine_merges_performed(apr_hash_t **merges, const char *target_wcpath,
> +                           svn_merge_range_t *range,
> +                           notification_receiver_baton_t *notify_b,
> +                           apr_pool_t *pool)
> +{
> +  apr_array_header_t *rangelist = apr_array_make(pool, 1, sizeof(*range));
> +  *merges = apr_hash_make(pool);
> +  APR_ARRAY_PUSH(rangelist, svn_merge_range_t *) = range;
> +  /* ### FIXME: What if the root of the target path wasn't merged
> +     ### either (e.g. only its children were)? */
> +  apr_hash_set(*merges, target_wcpath, APR_HASH_KEY_STRING, rangelist);
> +
> +  /* Override the merge info for child paths which weren't actually
> +     merged. */
> +  if (notify_b->skipped_paths != NULL)
> +    {
> +      int i;
> +      for (i = 0; i < notify_b->skipped_paths->nelts; i++)
> +        {
> +          /* Add an empty range list for this path. */
> +          /* ### Sometimes a path exists more than once... */
> +          apr_hash_set(*merges,
> +                       APR_ARRAY_IDX(notify_b->skipped_paths, i, const char *),
> +                       APR_HASH_KEY_STRING,
> +                       apr_array_make(pool, 0, sizeof(*range)));
> +        }
> +    }
> +
> +  return SVN_NO_ERROR;
> +}
> +
> +/* Calculate the new merge info for the target tree based on the merge
> +   info for TARGET_WCPATH and MERGES (a mapping of WC paths to range
> +   lists), and record it in the WC (at, and possibly below,
> +   TARGET_WCPATH). */
>  static svn_error_t *
>  update_wc_merge_info(const char *target_wcpath, const svn_wc_entry_t *entry,
> -                     const char *rel_path, apr_array_header_t *ranges,
> -                     svn_boolean_t is_revert, svn_wc_adm_access_t *adm_access,
> +                     const char *repos_rel_path, apr_hash_t *merges,
> +                     svn_boolean_t is_revert, svn_ra_session_t *ra_session,
>   
I could not see ra_session used anywhere? Is it needed?

With regards
Kamesh Jayachandran

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r20953 - branches/merge-tracking/subversion/libsvn_client

Posted by Daniel Rall <dl...@collab.net>.
On Thu, 03 Aug 2006, Kamesh Jayachandran wrote:
...
> >Log:
> >On the merge-tracking branch: Incremental progress towards
> >notification handling.  Not yet fully functional, but not expected to
> >break any previously working tests, either.
> >
> >* subversion/libsvn_client/diff.c
...
> >  (update_wc_merge_info): Rewrite this function to handle empty merge
> >   info, and re-purpose it to be called once per merge of an
> >   incremental revision range (as opposed to once after all revision
> >   ranges have been merged).  While somewhat less efficient, this is
> >   seems to be necessary to properly handle WC notifications.
...
> >+/* Calculate the new merge info for the target tree based on the merge
> >+   info for TARGET_WCPATH and MERGES (a mapping of WC paths to range
> >+   lists), and record it in the WC (at, and possibly below,
> >+   TARGET_WCPATH). */
> > static svn_error_t *
> > update_wc_merge_info(const char *target_wcpath, const svn_wc_entry_t 
> > *entry,
> >-                     const char *rel_path, apr_array_header_t *ranges,
> >-                     svn_boolean_t is_revert, svn_wc_adm_access_t 
> >*adm_access,
> >+                     const char *repos_rel_path, apr_hash_t *merges,
> >+                     svn_boolean_t is_revert, svn_ra_session_t 
> >*ra_session,
>
> I could not see ra_session used anywhere? Is it needed?

While it's not currently used in update_wc_merge_info(), it may be
necessary for retrieving any merge info from the repository for paths
other than target_wcpath which we want to set the merge info for.

If it's not, we'll remove it.  As probably evident from the change
log, this was more of a checkpoint commit -- I've had various
incarnations of this patch in my WC for weeks, and wanted to get it
under VC.