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

Tree conflicts - how's it going?

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 23 May 2008 15:48:15 +0100

For those interested in the tree conflicts, here's some notes on how I see the
design broken down into areas, and the status of implementation in each area in
the "tree-conflicts" branch.

Any thoughts or input would be appreciated.

- Julian

-----

Status and overview of tree-conflicts work.

Tree conflict handling spans the following areas:

   [DETECT] - detect tree conflicts during update/switch/merge
   [RECORD] - record them in the WC
   [DISPLAY] - display them (e.g. in "svn status")
   [COMMIT] - disallow commits while conflicts exist
   [RESOLVING] - help the user to resolve the conflict
   [RESOLVED] - enable the user to un-mark the conflict when resolved

[DETECT]
========

Purpose:

   Determine whether each incoming change conflicts with the state of the WC
   receiving the change. If so, record the fact and and ensure that sufficient
   information is preserved to enable the user to resolve the conflict. Allow
   the operation to continue on to process other items that are not affected by
   this conflict.

Status: incomplete

   As far as is currently tested by tree_conflict_tests.py, the status is:

   Detection of file conflicts: complete
   Detection of directory conflicts: 2 cases incomplete:
     - test 8: update add onto add (this is not a primary use case)
     - test 14: merge del onto changed (this is a primary use case)

Primary APIs:

   For update/switch:
     svn_delta_editor_t

   For merge:
     svn_wc_diff_callbacks3_t

Implemented in:

   For update/switch:
     subversion/libsvn_wc/update_editor.c
     (caution: the same code is also used for checkout)

   For merge:
     subversion/libsvn_client/merge.c

To do:

   * Fix test 14: merge deletes a changed dir. Needs to compare the dir
     currently in the target with the dir that was deleted from the merge-left
     source. If identical, allow the deletion. If not, conflict.

   * When raising a tree conflict on a dir victim, skip processing everything
     inside that dir. Check that files don't need similar "skip" handling, or
     are already getting it.

   * Check that a dir conflict on the root of an update/switch/merge is handled
     OK. It need not be handled the same as other dir conflicts, because there
     is no parent dir available. It just needs to fail in some reasonable way.

   * Pre-existing obstructions (status "~") or missing items ("!") should be
     detected first, before attempting to apply the change, and abort the
     operation.

   * Unversioned obstructions encountered while applying the change should be
     handled as a kind of tree conflict. (Given the pre-screening of
     obstructions to versioned items, this can only occur during add.)

Behaviour no longer wanted:

   Merge: "skipped missing target '...'". As a general principle, I'm wondering
   if it is no longer acceptable for a merge to skip anything without leaving a
   persistent record of what it did and why. If the target to be modified by
   the merge is missing from the target WC in the sense of no longer being
   under version control, we should instead raise a tree conflict. (If it's
   missing due to a known and already recorded reason, such as a shallow WC,
   that might be a bit different.)

[RECORD]
========

Purpose:

   A mechanism for recording, in the WC, what tree conflicts presently exist,
   and enough information to describe them to the user.

   Note: This is not the same as recording enough information in the WC to
   be able to resolve the conflict in any desired way without contacting the
   repository or source of the merge. For example, for a victim that is a
   directory, we might need to store or have access to both versions of the
   whole victim sub-tree. This problem comes under the [RESOLVING] section.

Status: complete enough to use.

Primary APIs:

   svn_wc_conflict_description_t

   /**
    * Read tree conflict descriptions from @a dir_entry.
    * Append pointers to newly allocated svn_wc_conflict_description_t
    * objects to the array pointed to by @a conflicts.
    * Do all allocations in @a pool.
    *
    * @since New in 1.6.
    */
   svn_error_t *
   svn_wc_read_tree_conflicts_from_entry(apr_array_header_t *conflicts,
                                         const svn_wc_entry_t *dir_entry,
                                         apr_pool_t *pool);

   /**
    * Add a tree conflict to the directory entry belonging to @a adm_access.
    * Pass a description of the new tree conflict in @a conflict.
    * Do all allocations in @a pool.
    *
    * @since New in 1.6.
    */
   svn_error_t *
   svn_wc_add_tree_conflict_data(svn_wc_conflict_description_t *conflict,
                                 svn_wc_adm_access_t *adm_access,
                                 apr_pool_t *pool);

To do:

   * APIs for getting a human-readable description are here in libsvn_wc,
     but should be moved to a higher (client) layer.

[DISPLAY]
=========

Status: complete enough to use, but wants improvement.

   "svn info"
     mechanism complete but ugly

   "svn status"
     mechanism complete

   "svn up/sw/merge" (progress notifications)
     mechanism complete

Primary APIs:

   "svn info"

   "svn status"

   "svn up/sw/merge" (progress notifications)

To do:

   * Design: conceptually, do we want to see conflicts on the parent directory
     or on the victims? Due to what falls out of the early implementation, we
     were heading for a concept of resolving the parent directory... but I
     don't feel that's right. See also [RESOLVED].

   * Clean up the "svn info" text: make it much less verbose.

   * Move the human-readable data up from libsvn_wc to libsvn_client or so
     - see [RECORD].

   * Consider whether "svn st ITEM" should show conflict on victim ITEM.

Notes:

   * Making the information available to be displayed is part of [DETECT].

[COMMIT]
========

Status: incomplete

   When parent and victim are included: complete?
   When only the parent is included: complete?
   When only the victim is included: incomplete

Purpose:

   Disallow commits while conflicts exist in the items proposed for commit.

   When directory D has a tree conflict on one or more children, what does
   that mean for
     (a) a child that is a victim?
     (b) a child that is not a victim?
     (c) the directory D, when treated as non-recursively (depth 0)?
   Answer:
     (a) Each victim is in conflict and cannot be committed, even if the
         "conflict" status information is stored in the parent D.
     (b) Each non-victim child is fine and can be committed independently
         of its parent.
     (c) NOT SURE... Could work either way.

To do:

   * Make commits fail when tree conflicts exist, even when the victim's parent
     is not part of the requested commit.

[RESOLVING]
===========

Purpose:

   Provide the user with tools and information and to resolve the conflicts.

Notes:

   * Not sure what's needed here.

[RESOLVED]
==========

Purpose:

   Enable the user to mark the conflict as Resolved, either with a command or
   interactively.

Status: incomplete

   By command: the basic "svn resolved PARENT" works to some extent, but needs
     attention.
     Issue #3145 <http://subversion.tigris.org/issues/show_bug.cgi?id=3145>

   Interactively: not started.
     Issue #3144 <http://subversion.tigris.org/issues/show_bug.cgi?id=3144>

To do:

   * Design: conceptually, do we want to "resolve" the parent directory or
     the victims? Due to what falls out of the early implementation, we were
     heading for a concept of resolving the parent directory... but I don't
     feel that's right. See also [DISPLAY].

   * Ensure the basic "resolved"/"resolve --accept=" works on a whole directory.

   * Allow individual victims to be marked as "resolved".

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-23 16:48:33 CEST

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