subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache subversion Wiki <>
Subject [Subversion Wiki] Update of "MergeCodeImprovements" by JulianFoad
Date Tue, 17 Apr 2012 11:59:22 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.

The "MergeCodeImprovements" page has been changed by JulianFoad:

Fill in: Prototype new merge code in Python; Single-file merge should be less of a special

+ === Prototype new merge code in Python ===
+ It would be extremely handy to be able to write new client-layer merge code in Python. 
The easiest way to start doing this would probably be to write a Python command-line program
that implements the equivalent of "svn merge" and uses either the swig-Python bindings or
the ctypes-Python bindings to access Subversion library APIs.  (In particular, don't try to
embed a Python merge module inside the 'svn' C program, unless somebody can show us how to
do that quickly and easily.)
  === Single-file merge should be less of a special case ===
+ I'm concerned that the present "single-file merge" code doesn't seem to have all the same
stuff in it that the directory merge code has.  It would be obviously correct if a single
"merge a node" function were called regardless whether the node is a file or a dir.
+ Some things can be simpler for a single file, of course.  It might seem obvious that it
doesn't need to think about subtrees, as a file can't have subtrees.  Even an assumption like
that, however, only holds if we don't allow a merge that replaces a file with a directory
or replaces a directory with a file.  I think we don't allow such a merge, on the basis that
two different kinds by definition are not ancestrally related, but that decision is not self-evident.
 We might want to structure the code such that the "merge" function at this level can merge
any arbitrary change that is encountered at a child level inside a (directory) merge, including
replacement of one node with another.  But I'm not suggesting we should re-structure the code
that way now, I'm just exploring a line of thought.
  === Use svn_client__pathrev_t more widely ===
  (Difficulty: several quite simple sub-tasks, and some harder bits)

View raw message