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: http://wiki.apache.org/subversion/MergeCodeImprovements?action=diff&rev1=5&rev2=6 Comment: Fill in: Prototype new merge code in Python; Single-file merge should be less of a special case + === 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)
