Re: Subversion merge or GIT merge?
Hi Peter, On Sun, Jan 30, 2011 at 12:16:04PM +, Peter Hancock wrote: Would the decision to move from SVN to another VCS be in the hands of the wider ASF community? The central repository is owned by the ASF and a decision to move is in the hands of the Apache Software Foundation membership. 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. I do not read infrastructure-...@apache.org, but I think that it is mainly a technical list, devoted a.o. to the development of the GIT front end to the ASF subversion repository. The political and legal issues of GIT vs. subversion are discussed on other lists. 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! The advantages, disadvantages, benefits and risks of GIT vs subversion have been discussed on the ASF email lists at length. I want to reiterate that for the ASF it is important that contributors _push_ the code which they want to contribute to an ASF project under their Contributor License Agreement. It cannot be _pulled_ by a committer. That is the main problem for the ASF in using a Distributed VCS. Legally it would be OK to submit a GIT patch. It might be useful to submit such a patch if you had agreed with a committer that they are willing to deal with your GIT patch. 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 Thanks for your considerations. Simon
Re: Subversion merge or GIT merge?
On Sat, Jan 29, 2011 at 02:08:29PM -0800, The Web Maestro wrote: Are you saying you think we should consider: a) moving from SVN to GIT I was careful not to make that suggestion. Such a move implies much more than merging. This has been discussed in the ASF and was rejected for now. The most important issue is the possibility to pull anyone's code changes. Apache projects must have a good overview of the provenance of their code; all code contributions must fall under a Copyright License Agreement with the ASF. It is not yet clear how that can be achieved with GIT. Every committer can decide for himself to use GIT via Apache's GIT mirror at https://github.com/apache/fop or http://git.apache.org/, and commit via git-svn. See http://www.apache.org/dev/git.html and http://wiki.apache.org/general/GitAtApache. As always, every committer must make sure that he commits his own code or code which was contributed to the ASF, via patches in bugzilla. b) using GIT as a timesaver for conflicts? That is up to every developer himself. I just note the possibility to do so, and my good experience with it. Simon 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
Re: Subversion merge or GIT merge? [was: Re: [VOTE] Merge FOP color branch into trunk]
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
Re: Subversion merge or GIT merge? [was: Re: [VOTE] Merge FOP color branch into trunk]
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
