Uploaded image for project: 'Subversion'
  1. Subversion
  2. SVN-3818

fix handling of externals in wc-ng

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: ---
    • Fix Version/s: 1.7.0
    • Component/s: libsvn_wc
    • Labels:
      None

      Description

      Currently, externals meta data is still hosted in svn:externals properties.
      Information about externals is obtained by parsing these properties, just like
      in 1.6. With wc-ng we have a chance to divide the actual meta data used to
      manage externals internally from the interface users use to configure them.
      The goal of this issue is to make internal handling of externals more
      straightforward by coming up with a new clean-room design and implementation for
      the externals feature (without changing the user interface part).
      
      The way externals (file *and* directory externals) are handled in wc-ng at the
      moment is problematic. It's not in a releasable state because there are
      regressions from 1.6 behaviour.
      
      For instance, it is currently impossible to flag a tree conflict on an external.
      External working copies still have their own wc.db. This causes problems with
      APIs such as svn_wc__db_wcroot_parse_local_abspath().
      If local_abspath is the root of an external, this API will open a wcroot for the
      wc.db within the external. The code flagging a conflict then tries to flag the
      conflict within the nested working copy. When that is worked around (by forcing
      the code flagging the conflict to open the wcroot for the parent working copy
      and flag the conflict in it), additional problems pop up. For instance, svn
      status fails to show the conflict on the external because it also uses
      svn_wc__db_wcroot_parse_local_abspath(), opens the external's wc.db, and doesn't
      see a conflict because the conflict was flagged in the parent.
      This problem was exposed by the reprodcution recipe issue 3469.
      
      It would be unwise to try to fix this by adding workarounds to all callers
      of svn_wc__db_wcroot_parse_local_abspath(). Instead, we should fix the
      underlying design problem.
      
      It would be better to have a non-ambiguous representation of externals in wc.db,
      with a set of new libsvn_wc APIs that can be used to manage externals, and maybe
      even a new API to manage wcroots (keying wcroots on local_abspath alone is
      probably a mistake!). If we do this smartly it could pave the way for managing
      multiple working copies (that don't have parent->child relationships like
      externals do) with a single wc.db later.
      

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                rhuijben Bert Huijben
                Reporter:
                stsp Stefan Sperling
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: