Mailing-List: contact commits-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@subversion.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Apache subversion Wiki <commits@subversion.apache.org>
To: Apache subversion Wiki <commits@subversion.apache.org>
Date: Tue, 17 Apr 2012 11:59:22 -0000
Message-ID: <20120417115922.12033.64383@eos.apache.org>
Subject: 
 =?utf-8?q?=5BSubversion_Wiki=5D_Update_of_=22MergeCodeImprovements=22_by_?=
 =?utf-8?q?JulianFoad?=
Auto-Submitted: auto-generated

Dear Wiki user,

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

The "MergeCodeImprovements" page has been changed by JulianFoad:
http://wiki.apache.org/subversion/MergeCodeImprovements?action=3Ddiff&rev1=
=3D5&rev2=3D6

Comment:
Fill in: Prototype new merge code in Python; Single-file merge should be le=
ss of a special case

+ =3D=3D=3D Prototype new merge code in Python =3D=3D=3D
+ It would be extremely handy to be able to write new client-layer merge co=
de in Python.  The easiest way to start doing this would probably be to wri=
te a Python command-line program that implements the equivalent of "svn mer=
ge" 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 Py=
thon merge module inside the 'svn' C program, unless somebody can show us h=
ow to do that quickly and easily.)
+ =

  =3D=3D=3D Single-file merge should be less of a special case =3D=3D=3D
+ I'm concerned that the present "single-file merge" code doesn't seem to h=
ave all the same stuff in it that the directory merge code has.  It would b=
e obviously correct if a single "merge a node" function were called regardl=
ess whether the node is a file or a dir.
+ =

+ Some things can be simpler for a single file, of course.  It might seem o=
bvious that it doesn't need to think about subtrees, as a file can't have s=
ubtrees.  Even an assumption like that, however, only holds if we don't all=
ow a merge that replaces a file with a directory or replaces a directory wi=
th a file.  I think we don't allow such a merge, on the basis that two diff=
erent kinds by definition are not ancestrally related, but that decision is=
 not self-evident.  We might want to structure the code such that the "merg=
e" function at this level can merge any arbitrary change that is encountere=
d 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.
+ =

  =3D=3D=3D Use svn_client__pathrev_t more widely =3D=3D=3D
  (Difficulty: several quite simple sub-tasks, and some harder bits)
 =20