Re: [VOTE] Merge FOP color branch into trunk

2011-02-10 Thread Jeremias Maerki
I've fixed the unit test errors. Thanks for running them on OpenJDK. I
didn't expect color management to differ so much between Java runtimes.

On 29.01.2011 21:06:58 Simon Pepping wrote:
 I paid a little attention to the conditions determining the type of
 ColorSpace, and came up with some questions:
 
 GraphicsSetProcessColor(Color color): Would it be possible to
 implement and use ColorSpace.getNumComponents() instead of hard coding
 the number of components here?

I've changed that as per your suggestion.

 GraphicsSetProcessColor.writeToStream and
 PtocaBuilder.setExtendedTextColor: Ideally the data written out are
 contained in the ColorSpace class instead of being contained in this
 method for all types of ColorSpace; are they not?

Sorry, but I don't understand what you're saying here.

 These are only minor points. Apart from the junit problems signalled
 in my earlier email, I am in favour of merging this work into trunk:
 +1.
 
 Thanks for this work.
 
 Simon
 
 On Sat, Jan 29, 2011 at 04:14:41PM +0100, Simon Pepping wrote:
  I get three failures on the color branch junit tests:
  
  java version 1.6.0_18
  OpenJDK Runtime Environment (IcedTea6 1.8.3) (6b18-1.8.3-2)
  OpenJDK Server VM (build 16.0-b13, mixed mode)
  OS: GNU/Linux (Debian testing)
  
  [echo] Apache Ant version 1.8.0 compiled on March 11 2010
  [echo] VM: 16.0-b13, Sun Microsystems Inc.
  
  [junit] Testcase: 
  testSeparationColor(org.apache.fop.util.ColorUtilTestCase):   FAILED
  [junit] expected:255.0 but was:250.0
  
  [junit] Testcase: 
  testNamedColorProfile(org.apache.fop.util.ColorUtilTestCase): FAILED
  [junit] expected:255.0 but was:253.0
  
  [junit] Testcase: 
  color_1.xml(org.apache.fop.intermediate.IntermediateFormatTestSuite$1):   
  FAILED
  [junit] org.custommonkey.xmlunit.Diff
  [junit] [different] Expected number of child nodes '14' but was '13' - 
  comparing viewport... at 
  /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1] to 
  viewport... at 
  /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1]
  
  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
   




Jeremias Maerki



Re: [VOTE] Merge FOP color branch into trunk

2011-02-10 Thread Jeremias Maerki
The color branch is now merged into Trunk:
http://svn.apache.org/viewvc?rev=1069439view=rev

Phew. Now Batik...


Jeremias Maerki



Re: [VOTE] Merge FOP color branch into trunk

2011-02-01 Thread Simon Pepping
You are right. I got confused by various issues in my tools.

The jar file was built by 'ant jar-main'. This target includes all
cruft that is present in the build directory. The build files could do
with an includes attribute in the jar task.

Simon

On Mon, Jan 31, 2011 at 09:12:10PM +0100, Jeremias Maerki wrote:
 Hi Simon
 
 Huh? What revision are you looking at? I've merged Trunk into Temp_Color
 on January 18 (http://svn.apache.org/viewvc?rev=1060241view=rev)
 copying the XGC.jar unchanged from Trunk. Temp_Color is long working
 against java2d.color and is compiling just fine like that. Looking at
 the XGC.jar in Trunk OTOH, it contains some junk in the root directory
 and test classes further down the hierarchy. If anything we need to
 rebuild the XGC.jar from Trunk and do another merge into Temp_Color.
 Something must have gone wrong during the compilation of that JAR.
 
 http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_Color/lib/xmlgraphics-commons-1.5svn.jar?view=logpathrev=1060241
 
 I'll look at your other points shortly. Thanks for the review.


Re: [VOTE] Merge FOP color branch into trunk

2011-02-01 Thread Jeremias Maerki
Hmm, I don't see how any cruft can accumulate in there. Main and test
classes are properly separated. jar-main only packs build/classes.
Anyway, when Andreas moves ColorProfileUtil to XGC (or shall I, Andreas?),
we need to update the JAR anyway.

On 01.02.2011 12:06:56 Simon Pepping wrote:
 You are right. I got confused by various issues in my tools.
 
 The jar file was built by 'ant jar-main'. This target includes all
 cruft that is present in the build directory. The build files could do
 with an includes attribute in the jar task.
 
 Simon
 
 On Mon, Jan 31, 2011 at 09:12:10PM +0100, Jeremias Maerki wrote:
  Hi Simon
  
  Huh? What revision are you looking at? I've merged Trunk into Temp_Color
  on January 18 (http://svn.apache.org/viewvc?rev=1060241view=rev)
  copying the XGC.jar unchanged from Trunk. Temp_Color is long working
  against java2d.color and is compiling just fine like that. Looking at
  the XGC.jar in Trunk OTOH, it contains some junk in the root directory
  and test classes further down the hierarchy. If anything we need to
  rebuild the XGC.jar from Trunk and do another merge into Temp_Color.
  Something must have gone wrong during the compilation of that JAR.
  
  http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_Color/lib/xmlgraphics-commons-1.5svn.jar?view=logpathrev=1060241
  
  I'll look at your other points shortly. Thanks for the review.




Jeremias Maerki



Re: [VOTE] Merge FOP color branch into trunk

2011-02-01 Thread Andreas Delmelle
On 01 Feb 2011, at 13:24, Jeremias Maerki wrote:

 Hmm, I don't see how any cruft can accumulate in there. Main and test
 classes are properly separated. jar-main only packs build/classes.
 Anyway, when Andreas moves ColorProfileUtil to XGC (or shall I, Andreas?),
 we need to update the JAR anyway.

Sure, I can take care of the migration of ColorProfileUtil in the same go. Do 
we move it to java2d.color.profile (similar to ColorUtil, which is placed under 
java2d.color)?

See attached patch XGC_ColorProfileUtil for the proposal. Just added a method 
to deal with the getInstance(byte[]) variant used in XGC, and for the sake of 
completeness, provided one for the String variant as well.

Additionally, looked up the places where one of the getInstance() methods was 
being used and replaced them by a corresponding call to 
ColorProfileUtil.getICC_Profile(). 
As it turns out, there were only two occurrences: ImageLoaderRawJPEG and 
ImageLoaderImageIO.

Are there any special steps to be taken to replace the JAR in FOP, or do I just 
commit the new '...1.5svn' JAR?

On FOP's end, after the JAR has been replaced, the changes then become as in 
attached patch FOP_ColorProfileUtil. For now, I deprecated the class and 
redirected the existing methods. The calls to getICC_Profile() are done 
directly against XGC, so no need to add those to FOP's ColorProfileUtil 
anymore. I also cleaned up the remaining references to other methods (= 
basically just replaced import statements in the affected classes), so 
fop.util.ColorProfileUtil is actually unused. To be removed at a later date?

The harder part would be to come up with some test cases, in order to verify 
that this actually fixes the behavior... Notoriously difficult in the case of 
race conditions, especially if they are located in code that is outside of our 
control.




XGC_ColorProfileUtil.diff
Description: Binary data


FOP_ColorProfileUtil.diff
Description: Binary data



Regards,

Andreas
---



Re: [VOTE] Merge FOP color branch into trunk

2011-02-01 Thread Jeremias Maerki
Looks perfect. Thanks! If it's not too much trouble, please svn copy
the ColorProfileUtil from FOP Trunk so we retain the history and
document where this came from.

I don't think it makes sense to put a lot of time in trying to test for
a race condition. That's going to be difficult to reproduce. And to
prove that it's no longer there. For me, the important thing is that
this problem is documented in ColorProfileUtil like you did.

For the JAR: just do a clean compile (with Java 1.5, i.e. lowest
possible) and replace the ...1.5svn.jar in FOP's lib directory.

On 01.02.2011 19:40:38 Andreas Delmelle wrote:
 On 01 Feb 2011, at 13:24, Jeremias Maerki wrote:
 
  Hmm, I don't see how any cruft can accumulate in there. Main and test
  classes are properly separated. jar-main only packs build/classes.
  Anyway, when Andreas moves ColorProfileUtil to XGC (or shall I, Andreas?),
  we need to update the JAR anyway.
 
 Sure, I can take care of the migration of ColorProfileUtil in the same go. Do 
 we move it to java2d.color.profile (similar to ColorUtil, which is placed 
 under java2d.color)?
 
 See attached patch XGC_ColorProfileUtil for the proposal. Just added a method 
 to deal with the getInstance(byte[]) variant used in XGC, and for the sake of 
 completeness, provided one for the String variant as well.
 
 Additionally, looked up the places where one of the getInstance() methods was 
 being used and replaced them by a corresponding call to 
 ColorProfileUtil.getICC_Profile(). 
 As it turns out, there were only two occurrences: ImageLoaderRawJPEG and 
 ImageLoaderImageIO.
 
 Are there any special steps to be taken to replace the JAR in FOP, or do I 
 just commit the new '...1.5svn' JAR?
 
 On FOP's end, after the JAR has been replaced, the changes then become as in 
 attached patch FOP_ColorProfileUtil. For now, I deprecated the class and 
 redirected the existing methods. The calls to getICC_Profile() are done 
 directly against XGC, so no need to add those to FOP's ColorProfileUtil 
 anymore. I also cleaned up the remaining references to other methods (= 
 basically just replaced import statements in the affected classes), so 
 fop.util.ColorProfileUtil is actually unused. To be removed at a later date?
 
 The harder part would be to come up with some test cases, in order to verify 
 that this actually fixes the behavior... Notoriously difficult in the case of 
 race conditions, especially if they are located in code that is outside of 
 our control.
 
 




Jeremias Maerki



Re: [VOTE] Merge FOP color branch into trunk

2011-02-01 Thread Andreas Delmelle
On 01 Feb 2011, at 20:23, Jeremias Maerki wrote:

 Looks perfect. Thanks! If it's not too much trouble, please svn copy
 the ColorProfileUtil from FOP Trunk so we retain the history and
 document where this came from.

Done. All related changes committed to both XGC and FOP.


Regards,

Andreas
---



Re: [VOTE] Merge FOP color branch into trunk

2011-02-01 Thread Jeremias Maerki
Thanks, Andreas!

On 01.02.2011 21:09:15 Andreas Delmelle wrote:
 On 01 Feb 2011, at 20:23, Jeremias Maerki wrote:
 
  Looks perfect. Thanks! If it's not too much trouble, please svn copy
  the ColorProfileUtil from FOP Trunk so we retain the history and
  document where this came from.
 
 Done. All related changes committed to both XGC and FOP.
 
 
 Regards,
 
 Andreas
 ---




Jeremias Maerki



Re: [VOTE] Merge FOP color branch into trunk

2011-01-31 Thread Jeremias Maerki
Hi Simon

Huh? What revision are you looking at? I've merged Trunk into Temp_Color
on January 18 (http://svn.apache.org/viewvc?rev=1060241view=rev)
copying the XGC.jar unchanged from Trunk. Temp_Color is long working
against java2d.color and is compiling just fine like that. Looking at
the XGC.jar in Trunk OTOH, it contains some junk in the root directory
and test classes further down the hierarchy. If anything we need to
rebuild the XGC.jar from Trunk and do another merge into Temp_Color.
Something must have gone wrong during the compilation of that JAR.

http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_Color/lib/xmlgraphics-commons-1.5svn.jar?view=logpathrev=1060241

I'll look at your other points shortly. Thanks for the review.

On 30.01.2011 12:36:10 Simon Pepping wrote:
 I noticed that the XGC jar file in the Temp_Color branch differs from
 the current state of the XGC code in an important aspect for the
 Temp_Color branch: A number of classes, e.g. ColorWithAlternatives,
 have been moved from package java2d to java2d.color. I think that that
 change must be made in the Temp_Color branch before the merge. If not,
 the change must be made at the moment when the XGC jar file is
 updated, which is not a good moment.
 
 That changes my vote to -1 for the moment, until this change has been
 made.
 
 Simon
 
 On Sat, Jan 29, 2011 at 09:06:58PM +0100, Simon Pepping wrote:
  I paid a little attention to the conditions determining the type of
  ColorSpace, and came up with some questions:
  
  GraphicsSetProcessColor(Color color): Would it be possible to
  implement and use ColorSpace.getNumComponents() instead of hard coding
  the number of components here?
  
  GraphicsSetProcessColor.writeToStream and
  PtocaBuilder.setExtendedTextColor: Ideally the data written out are
  contained in the ColorSpace class instead of being contained in this
  method for all types of ColorSpace; are they not?
  
  These are only minor points. Apart from the junit problems signalled
  in my earlier email, I am in favour of merging this work into trunk:
  +1.
  
  Thanks for this work.
  
  Simon
  
  On Sat, Jan 29, 2011 at 04:14:41PM +0100, Simon Pepping wrote:
   I get three failures on the color branch junit tests:
   
   java version 1.6.0_18
   OpenJDK Runtime Environment (IcedTea6 1.8.3) (6b18-1.8.3-2)
   OpenJDK Server VM (build 16.0-b13, mixed mode)
   OS: GNU/Linux (Debian testing)
   
   [echo] Apache Ant version 1.8.0 compiled on March 11 2010
   [echo] VM: 16.0-b13, Sun Microsystems Inc.
   
   [junit] Testcase: 
   testSeparationColor(org.apache.fop.util.ColorUtilTestCase): FAILED
   [junit] expected:255.0 but was:250.0
   
   [junit] Testcase: 
   testNamedColorProfile(org.apache.fop.util.ColorUtilTestCase):   FAILED
   [junit] expected:255.0 but was:253.0
   
   [junit] Testcase: 
   color_1.xml(org.apache.fop.intermediate.IntermediateFormatTestSuite$1): 
   FAILED
   [junit] org.custommonkey.xmlunit.Diff
   [junit] [different] Expected number of child nodes '14' but was '13' - 
   comparing viewport... at 
   /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1] to 
   viewport... at 
   /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1]
   
   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





Jeremias Maerki



Re: [VOTE] Merge FOP color branch into trunk

2011-01-30 Thread Simon Pepping
I noticed that the XGC jar file in the Temp_Color branch differs from
the current state of the XGC code in an important aspect for the
Temp_Color branch: A number of classes, e.g. ColorWithAlternatives,
have been moved from package java2d to java2d.color. I think that that
change must be made in the Temp_Color branch before the merge. If not,
the change must be made at the moment when the XGC jar file is
updated, which is not a good moment.

That changes my vote to -1 for the moment, until this change has been
made.

Simon

On Sat, Jan 29, 2011 at 09:06:58PM +0100, Simon Pepping wrote:
 I paid a little attention to the conditions determining the type of
 ColorSpace, and came up with some questions:
 
 GraphicsSetProcessColor(Color color): Would it be possible to
 implement and use ColorSpace.getNumComponents() instead of hard coding
 the number of components here?
 
 GraphicsSetProcessColor.writeToStream and
 PtocaBuilder.setExtendedTextColor: Ideally the data written out are
 contained in the ColorSpace class instead of being contained in this
 method for all types of ColorSpace; are they not?
 
 These are only minor points. Apart from the junit problems signalled
 in my earlier email, I am in favour of merging this work into trunk:
 +1.
 
 Thanks for this work.
 
 Simon
 
 On Sat, Jan 29, 2011 at 04:14:41PM +0100, Simon Pepping wrote:
  I get three failures on the color branch junit tests:
  
  java version 1.6.0_18
  OpenJDK Runtime Environment (IcedTea6 1.8.3) (6b18-1.8.3-2)
  OpenJDK Server VM (build 16.0-b13, mixed mode)
  OS: GNU/Linux (Debian testing)
  
  [echo] Apache Ant version 1.8.0 compiled on March 11 2010
  [echo] VM: 16.0-b13, Sun Microsystems Inc.
  
  [junit] Testcase: 
  testSeparationColor(org.apache.fop.util.ColorUtilTestCase):   FAILED
  [junit] expected:255.0 but was:250.0
  
  [junit] Testcase: 
  testNamedColorProfile(org.apache.fop.util.ColorUtilTestCase): FAILED
  [junit] expected:255.0 but was:253.0
  
  [junit] Testcase: 
  color_1.xml(org.apache.fop.intermediate.IntermediateFormatTestSuite$1):   
  FAILED
  [junit] org.custommonkey.xmlunit.Diff
  [junit] [different] Expected number of child nodes '14' but was '13' - 
  comparing viewport... at 
  /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1] to 
  viewport... at 
  /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1]
  
  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]

2011-01-30 Thread Peter Hancock
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: [VOTE] Merge FOP color branch into trunk

2011-01-29 Thread Simon Pepping
I get three failures on the color branch junit tests:

java version 1.6.0_18
OpenJDK Runtime Environment (IcedTea6 1.8.3) (6b18-1.8.3-2)
OpenJDK Server VM (build 16.0-b13, mixed mode)
OS: GNU/Linux (Debian testing)

[echo] Apache Ant version 1.8.0 compiled on March 11 2010
[echo] VM: 16.0-b13, Sun Microsystems Inc.

[junit] Testcase: testSeparationColor(org.apache.fop.util.ColorUtilTestCase):   
FAILED
[junit] expected:255.0 but was:250.0

[junit] Testcase: testNamedColorProfile(org.apache.fop.util.ColorUtilTestCase): 
FAILED
[junit] expected:255.0 but was:253.0

[junit] Testcase: 
color_1.xml(org.apache.fop.intermediate.IntermediateFormatTestSuite$1):   
FAILED
[junit] org.custommonkey.xmlunit.Diff
[junit] [different] Expected number of child nodes '14' but was '13' - 
comparing viewport... at 
/document[1]/page-sequence[1]/page[1]/content[1]/viewport[1] to viewport... 
at /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1]

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: [VOTE] Merge FOP color branch into trunk

2011-01-29 Thread Simon Pepping
I paid a little attention to the conditions determining the type of
ColorSpace, and came up with some questions:

GraphicsSetProcessColor(Color color): Would it be possible to
implement and use ColorSpace.getNumComponents() instead of hard coding
the number of components here?

GraphicsSetProcessColor.writeToStream and
PtocaBuilder.setExtendedTextColor: Ideally the data written out are
contained in the ColorSpace class instead of being contained in this
method for all types of ColorSpace; are they not?

These are only minor points. Apart from the junit problems signalled
in my earlier email, I am in favour of merging this work into trunk:
+1.

Thanks for this work.

Simon

On Sat, Jan 29, 2011 at 04:14:41PM +0100, Simon Pepping wrote:
 I get three failures on the color branch junit tests:
 
 java version 1.6.0_18
 OpenJDK Runtime Environment (IcedTea6 1.8.3) (6b18-1.8.3-2)
 OpenJDK Server VM (build 16.0-b13, mixed mode)
 OS: GNU/Linux (Debian testing)
 
 [echo] Apache Ant version 1.8.0 compiled on March 11 2010
 [echo] VM: 16.0-b13, Sun Microsystems Inc.
 
 [junit] Testcase: testSeparationColor(org.apache.fop.util.ColorUtilTestCase): 
 FAILED
 [junit] expected:255.0 but was:250.0
 
 [junit] Testcase: 
 testNamedColorProfile(org.apache.fop.util.ColorUtilTestCase):   FAILED
 [junit] expected:255.0 but was:253.0
 
 [junit] Testcase: 
 color_1.xml(org.apache.fop.intermediate.IntermediateFormatTestSuite$1): 
 FAILED
 [junit] org.custommonkey.xmlunit.Diff
 [junit] [different] Expected number of child nodes '14' but was '13' - 
 comparing viewport... at 
 /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1] to viewport... 
 at /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1]
 
 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
  


Subversion merge or GIT merge? [was: Re: [VOTE] Merge FOP color branch into trunk]

2011-01-29 Thread Simon Pepping
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]

2011-01-29 Thread The Web Maestro
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: [VOTE] Merge FOP color branch into trunk

2011-01-21 Thread Andreas Delmelle
On 19 Jan 2011, at 11:56, 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.

No detailed review done here, but from what I did see, it indeed looks good, so

+1


Regards,

Andreas
---



Re: [VOTE] Merge FOP color branch into trunk

2011-01-21 Thread The Web Maestro
No formal review but the code looks good. 

+1

Sent from my iPhone

On Jan 19, 2011, at 2:56 AM, Jeremias Maerki d...@jeremias-maerki.ch 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: [VOTE] Merge FOP color branch into trunk

2011-01-21 Thread Adrian Cumiskey
I'm afraid I've not had time to review so +0.

Cheers, Adrian.

On Jan 22, 2011, at 6:04 AM, The Web Maestro the.webmaes...@gmail.com wrote:

 No formal review but the code looks good. 
 
 +1
 
 Sent from my iPhone
 
 On Jan 19, 2011, at 2:56 AM, Jeremias Maerki d...@jeremias-maerki.ch 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