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 consideration. 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. Pete 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 >>> >