Would the decision to move from SVN to another VCS be in the hands of
the wider ASF community?

Discussions about migrating from SVN to GIT are often held on
infrastructure-...@apache.org and I imagine it is only a matter of
time before this happens across the projects, and with sensible

GIT certainly makes the creation and merging of branches easier to
manage and this is just one of many features that FOP developers would
gain from a switch to GIT or another DVCS (Distributed VCS).  Another
aspect of particular interest to contributors without committer status
is that a DVCS gives every developer first class version control of
their local development workflow, something that is not possible using
SVN alone.
Combining both SVN and GIT can get you a long way but as long as SVN
is the central VCS there will remain a steep learning curve required
to contribute effectively to FOP, and no satisfactory way of
addressing the issue of submitting patches:  Currently, contributors
are encouraged to submit SVN compatible diffs to a Bugzilla issue,
however this format does not contain the richness of information
potential contained within a series local GIT commits.  Submitting a
GIT generated diff preserves the original workflow, but then defers
the responsibility of handling the GiT SVN bridge onto the committer,
further adding a layer of complexity to a job that the time stretched
few currently struggle to keep on top of!

I find GIT an indispensable tool and encourage all members of this
community to investigate GIT, or perhaps other next generation DVCS
(Distributed VCS), and see how they may help on both an individual and
collaborative basis.


On Sat, Jan 29, 2011 at 10:08 PM, The Web Maestro
<the.webmaes...@gmail.com> wrote:
> Are you saying you think we should consider:
> a) moving from SVN to GIT
> b) using GIT as a timesaver for conflicts?
> Clay
> Sent from my iPhone
> On Jan 29, 2011, at 12:24 PM, Simon Pepping <spepp...@leverkruid.eu> wrote:
>> I read in the literature that GIT and Mercurial merge would be very
>> much better at resolving possible conflicts than subversion. Today I
>> tested this with the merge of the Temp_Color branch into trunk.
>> In GIT I used the GIT repository at https://github.com/apache/fop. The
>> merge of Temp_Color resulted in one conflict, in status.xml. The
>> conflict was presented precisely, and was easily resolved.
>> The merge in Subversion resulted in the following:
>> Summary of conflicts:
>>  Text conflicts: 16
>>  Property conflicts: 1
>>  Tree conflicts: 68
>> The many tree conflicts were files that were removed in the branch and
>> trunk or added in both. Obviously they were caused by the merges of
>> trunk into Temp_Color earlier.
>> After the merge in GIT I got no compilation errors. I got three
>> failures in the junit tests, which were also present in the branch. I
>> investigated a few cases which gave a conflict in subversion. They
>> were resolved correctly in GIT.
>> This merge result is a huge time saver, and I thought I should let you
>> know.
>> Simon
>> On Wed, Jan 19, 2011 at 11:56:34AM +0100, Jeremias Maerki wrote:
>>> I've cleaned up the color branch, tweaked a few things and did some more
>>> testing. I'm happy with the current state, so I'm calling for a vote to
>>> merge the current FOP color branch into trunk.
>>> https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Color
>>> +1 from me, obviously.
>>> Jeremias Maerki

Reply via email to