Re: What about a Composer plugin?

2013-04-26 Thread Bruno P. Kinoshita
Hi Renan, 
I've already added Composer to my CodeIgniter project and am now getting my 
feet wet with packagist, composer, eclipse+composer, etc.
I'll keep an eye on the repository and will create a branch to send some code 
too.
> Just a note, I will be back to the office in July. That's all I can do for 
>now. I will give more effective feedbacks when I come back, anyway... it's 
>done, we have a mission.
Enjoy your vacation. As we say in Brazil: missão dada é missão cumprida :) 
(mission given is mission accomplished).

Thanks!

Bruno P. Kinoshita

http://kinoshita.eti.br

http://tupilabs.com

--- Em sex, 26/4/13, Renan de Lima  escreveu:

De: Renan de Lima 
Assunto: Re: What about a Composer plugin?
Para: jenkinsci-dev@googlegroups.com
Data: Sexta-feira, 26 de Abril de 2013, 21:08

Bruno,
I've created https://github.com/renanbr/composer-plugin repository. You are 
collaborator =)Next week some people will start coding, they also have access 
to manage pull request.


I'll ping composer-dev group about what we are doing.
Just a note, I will be back to the office in July. That's all I can do for now. 
I will give more effective feedbacks when I come back, anyway... it's done, we 
have a mission.


thanks
--
Renan de Lima Barbosa


On 25 April 2013 16:01, Bruno P. Kinoshita  wrote:


Hello, 


>Before talk about Composer, some words about build.xml. Actually we are moving 
>from Phing to Ant for some reasons:>    - Ant makes projects more pluggable 
>for IDEs, CI Servers... (less shell)

>    - Ant is recommended in http://jenkins-php.org>    - Ant is faster than 
> Phing
>    - Ant parallel task is stable, Phing task is not
>What do you think about this?
ATM I'm using Ant as it's easier for me - I use Java and Maven or Ivy+Ant for 
most of my projects.


I only thought about Phing because I found its Eclipse plugin in the same 
update site of Composer plug-in [1].


> If possible, I would like to know more about your migration project and how 
> you are planning this.
My current project is a website that uses Continuous Integration + Continuous 
Delivery with 

Ant + Rsync. We're adding applications (mobile apps, facebook, etc) and we'll 
need to add a few dependencies to this project. 


So far, the way we did this was by unzipping the PHP libraries to the CI 
application/libraries folder. What is not the more elegant solution, but works. 
Now we are working to create a 

REST API and add these libraries with Composer. 
One alternative is migrating from CI to FuelPHP, so we could drop TankAuth 
authentication 

library in favor of FuelPHP's bundled auth library, and use REST controllers 
provided by FuelPHP (no library needed for this too). 


One thing that I would like to see
 in this plug-in, is looking at my job and being able to spot all the 
dependencies (name/version) used in Composer.


> It's my first contact with Jenkins CI Community. I don't know how plugins > 
> life cycle works neither how mature the idea must be to start coding. We 

> have a laboratory sector to try some contexts as well. I have some Java > 
> skilled guys in my DevOps team, we can help when possible.>

> Ready to go! Just waiting your signal to start.
I believe
 there is no plug-in for this, and a lot of PHP users would like to use it. If 
you create a GitHub repository to work on this plug-in, you can send me the 
link and I'll take a look to see if I can help you guys.


Once the code is stable enough, we can ask here to fork the repository, create 
theWiki page + JIRA component for this new plug-in and prepare for the initial 
release. 


How does that sound to you?
Cheers, 


[1]
 http://p2.dubture.com/
Bruno P. Kinoshita

http://kinoshita.eti.br

http://tupilabs.com

--- Em qui, 25/4/13, Renan de Lima  escreveu:



De: Renan de Lima 


Assunto: Re: What about a Composer plugin?
Para: jenkinsci-dev@googlegroups.com
Data: Quinta-feira, 25 de Abril de 2013, 9:03



Hi there,

I'm migrating a few projects from CodeIgniter (+bunch of libraries and sparks) 
to FuelPHP and to CodeIgniter+Composer, and am having to learn Composer. 

> Is there any activity
 to integrate Composer and Jenkins?Not that I'm aware of.> Is there a better 
way to use Composer through Jenkins?In my todo-list, right next to Composer is 
Phing. I haven't had time to read all the docs about Composer, but I want to 
understand if you have to run composer or if you can call it in phing scripts. 
What do you think?


Before talk about Composer, some words about build.xml. Actually we are moving 
from Phing to Ant for some reasons:    - Ant makes projects more pluggable for 
IDEs, CI Servers... (less shell)


    - Ant is recommended in http://jenkins-php.org    - Ant is faster than 
Phing    - Ant parallel task is stable, Phing task is not


What do you think about this?
Getting back to Composer plugin... We are planning two kinds of job for every 
project:
    - build-job: for every project development line (trunk, branches...). This 
job executes quali

Re: What about a Composer plugin?

2013-04-26 Thread Renan de Lima
Bruno,

I've created https://github.com/renanbr/composer-plugin repository. You are
collaborator =)
Next week some people will start coding, they also have access to manage
pull request.

I'll ping composer-dev group about what we are doing.

Just a note, I will be back to the office in July. That's all I can do for
now. I will give more effective feedbacks when I come back, anyway... it's
done, we have a mission.

thanks

--
Renan de Lima Barbosa


On 25 April 2013 16:01, Bruno P. Kinoshita wrote:

> Hello,
>
> >Before talk about Composer, some words about build.xml. Actually we are
> moving from Phing to Ant for some reasons:
> >- Ant makes projects more pluggable for IDEs, CI Servers... (less
> shell)
> >- Ant is recommended in http://jenkins-php.org
> >- Ant is faster than Phing
> >- Ant parallel task is stable, Phing task is not
> >What do you think about this?
>
> ATM I'm using Ant as it's easier for me - I use Java and Maven or Ivy+Ant
> for most of my projects.
>
> I only thought about Phing because I found its Eclipse plugin in the same
> update site of Composer plug-in [1].
>
> > If possible, I would like to know more about your migration project and
> how you are planning this.
>
> My current project is a website that uses Continuous Integration +
> Continuous Delivery with
> Ant + Rsync. We're adding applications (mobile apps, facebook, etc) and
> we'll need
> to add a few dependencies to this project.
>
> So far, the way we did this was by unzipping the PHP libraries to the CI
> application/libraries
> folder. What is not the more elegant solution, but works. Now we are
> working to create a
> REST API and add these libraries with Composer.
>
> One alternative is migrating from CI to FuelPHP, so we could drop TankAuth
> authentication
> library in favor of FuelPHP's bundled auth library, and use REST
> controllers provided
> by FuelPHP (no library needed for this too).
>
> One thing that I would like to see in this plug-in, is looking at my job
> and
> being able to spot all the dependencies (name/version) used in Composer.
>
> > It's my first contact with Jenkins CI Community. I don't know how
> plugins
> > life cycle works neither how mature the idea must be to start coding. We
> > have a laboratory sector to try some contexts as well. I have some Java
> > skilled guys in my DevOps team, we can help when possible.
> >
> > Ready to go! Just waiting your signal to start.
>
> I believe there is no plug-in for this, and a lot of PHP users would like
> to use it.
> If you create a GitHub repository to work on this plug-in, you can send me
> the link
> and I'll take a look to see if I can help you guys.
>
> Once the code is stable enough, we can ask here to fork the repository,
> create the
> Wiki page + JIRA component for this new plug-in and prepare for the
> initial release.
>
> How does that sound to you?
>
> Cheers,
>
> [1] http://p2.dubture.com/
>
> Bruno P. Kinoshita
> http://kinoshita.eti.br
> http://tupilabs.com
>
> --- Em *qui, 25/4/13, Renan de Lima * escreveu:
>
>
> De: Renan de Lima 
> Assunto: Re: What about a Composer plugin?
> Para: jenkinsci-dev@googlegroups.com
> Data: Quinta-feira, 25 de Abril de 2013, 9:03
>
> Hi there,
>
> I'm migrating a few projects from CodeIgniter (+bunch of libraries and
> sparks) to FuelPHP and to CodeIgniter+Composer, and am having to learn
> Composer.
>
> > Is there any activity to integrate Composer and Jenkins?
>
> Not that I'm aware of.
>
> > Is there a better way to use Composer through Jenkins?
>
> In my todo-list, right next to Composer is Phing. I haven't had time to
> read all the docs about Composer, but I want to understand if you have to
> run composer or if you can call it in phing scripts. What do you think?
>
>
> Before talk about Composer, some words about build.xml. Actually we are
> moving from Phing to Ant for some reasons:
> - Ant makes projects more pluggable for IDEs, CI Servers... (less
> shell)
> - Ant is recommended in http://jenkins-php.org
> - Ant is faster than Phing
> - Ant parallel task is stable, Phing task is not
> What do you think about this?
>
> Getting back to Composer plugin... We are planning two kinds of job for
> every project:
> - build-job: for every project development line (trunk, branches...).
> This job executes quality checks as described in http://jenkins-php.orgIt 
> also generates tags;
> - deploy-job: one per project, it sends files of a package version to
> the web servers.
>
> For build-job, Composer is necessary to get dependencies before to run
> Ant/Phing build.xml (http://getcomposer.org/doc/ 
> 03-cli.md#installand 
> http://getcomposer.org/doc/03-
> cli.md#update ). Here is the
> reason of "Invoke Composer".
>
> Note: every project is plugged in a private repository 
> (https://github.com/composer/
> satis  and https://github.com/co

Re: Question on Jenkin

2013-04-26 Thread Kenny Ayers
Hey avineet,

  The procurement cost of Jenkins is free.  The real cost will be in 
implementation and development man hours by your build person (or team). 
 As far as your use-cases go, it's up to your build person or team to 
implement the functionality using the Jenkins toolset.

  If you don't have anyone in-house that can answer those questions on 
feasibility, it's probably time for a new hire.

Good luck,

Kenny

On Friday, April 26, 2013 3:05:18 AM UTC-7, avineet wrote:
>
> Hi,
> We wanted to implement Jenkin in our project which require some kind of 
> automation tool which support testing around Abnitio.
> I have heard that Jenkin works with Abnitio,Could you please confirm me 
> the same.
> *What would be the Procurement cost of the product.
> *
> Also,I drafted few high level cases which we want the tool should 
> support.Could anyone please have a look and let me know if these cases 
> works with Jenkin.
>
> Compare input and output record counts
> Compare input values and output values
> Validates transformations
> Compares checksums created against the input and output (e.g. The sum 
> of input column 1 = sum of output column 1)
> Compare input with a filter record count with output record count
> Supports files and tables as either the input or output (File to 
> Table, Table to Table, Table to File)
> Supports the validation of a test against a static value, e.g. Sum of 
> column 1 = value x
> Supports embedded SQL to use for the validation routine, e.g. Output 
> of SQL 1 is equal to the output of SQL 2 or Output of SQL 1 is equal to 
> this 

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: request for plugin hosting

2013-04-26 Thread Geoff Bullen
I didn't have any joy on IRC.   Any chance you could see why I can't push?

On 25 April 2013 09:37, geoff  wrote:

> OK.  I'm trying out IRC for the first time...  No one there yet :-) maybe
> as I'm in Oz..
>
> On Thursday, 25 April 2013 01:10:21 UTC+10, Ullrich Hafner wrote:
>>
>> The best would be if you join us on IRC. Then we can give you the karma
>> to add committers on your own…
>>
>> Ulli
>>
>> Am 24.04.2013 um 00:55 schrieb Geoff Bullen > >**:
>>
>> Thanks for that...  A couple of follow ups...
>>
>> 1) I'm unable to commit my updated POM!  How do I get access??  Permission
>> to jenkinsci/build-pipeline-**plugin.git denied to geoffbullen I seem to
>> be a member...
>>
>> 2) Can I have a CI build set up please?
>>
>> 3) I have a few commiters to this project (from google code) how do I
>> grant them access to the github repo?
>>
>> Thanks,
>>
>> *Geoff Bullen *
>> Centrum Systems
>> Level 8, 5 Elizabeth Street
>> Sydney
>>
>> *0408 659 395 (m)
>> 02 9235 0516 (t)** *
>> http://www.centrumsystems.com.**au 
>>
>>
>> On 23 April 2013 17:36, Ulli Hafner  wrote:
>>
>>> Done: 
>>> https://github.com/**jenkinsci/build-pipeline-**plugin
>>>
>>>
>>> You need to update your pom.xml in order to get the SCM information
>>> showing up correctly in https://wiki.jenkins-ci.**
>>> org/display/JENKINS/Build+**Pipeline+Plugin
>>>
>>> Welcome aboard!
>>>
>>> Ulli
>>>
>>> Am 23.04.2013 um 02:26 schrieb Geoff Bullen <
>>> geo...@centrumsystems.com.au>**:
>>>
>>> I have added it to github...
>>>
>>> https://github.com/**geoffbullen/build-pipeline-**plugin
>>>
>>>
>>> *Geoff Bullen *
>>> Centrum Systems
>>> Level 8, 5 Elizabeth Street
>>> Sydney
>>>
>>> *0408 659 395 (m)
>>> 02 9235 0516 (t)** *
>>> http://www.centrumsystems.com.**au 
>>>
>>>
>>> On 20 April 2013 17:41, domi  wrote:
>>>
 easiest is:
 1. move it to GH under your account
 2. ask for forking here again.
 /Domi

 On 20.04.2013, at 00:10, Geoff Bullen 
 wrote:

 Hey,

 I'd like to move a plugin (currently hosted on google) into the
 jenkins-ci.   Can you create the repo and give me access please??

 *github ID:* geoffbullen
 *Plugin name:* build-pipeline-plugin

 Thanks!

 Geoff


>>  --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: A possible fix for Jenkins-14551 - subversion-plugin duplicating file contents

2013-04-26 Thread Kenny Ayers
Ah, I see... perhaps I can bribe him with mail-order cookies or beer or 
something...

I'll do a pull request on my change, and see if that gets the ball rolling.

Thanks for the replies,

Kenny

On Friday, April 26, 2013 2:45:04 PM UTC-7, Stephen Connolly wrote:
>
> The process I usually follow is to beg KK to do the merge pleading that it 
> blew up in my face and there is no way he could do it during his 
> lunchbreak...
>
> Though I may be using the "no way you could do that in your lunchbreak" 
> dare a bit too often... he may have wised up to my tricks... perhaps I need 
> to find a new one ;-)
>
>
> On 26 April 2013 22:39, Kenny Ayers  >wrote:
>
>> Hey Stephen,
>>
>>   Alexander Kitaev from SVNKit has peer-reviewed this change and has 
>> rolled it into the upstream libraries, and the new binaries are available 
>> here: 
>> http://teamcity.tmatesoft.com/viewLog.html?buildId=6105&tab=artifacts&buildTypeId=bt43(
>> http://issues.tmatesoft.com/issue/SVNKIT-368#comment=60-4930).  I'm not 
>> sure what the process is for getting this updated in the plugin, please let 
>> me know if there is anything else I can do to help.
>>
>> Thank you,
>>
>> Kenny
>>
>>
>> On Friday, April 26, 2013 3:04:03 AM UTC-7, Stephen Connolly wrote:
>>
>>> Traditionally, the jenkins fork is maintaining a (hopefully) smaller set 
>>> of patches on top of the upstream version.
>>>
>>> The aim is to get the set of patches to zero and then drop the fork.
>>>
>>> With reference to the above aim, my preference would be to get it in 
>>> upstream rather than add to our current patch set.
>>>
>>> It is a real pain trying to update the code from upstream, at least 
>>> every time I have tried I have had to give up and get KK to do it (he has 
>>> some set of magic workspaces or something) so I would just love if we can 
>>> get the need for this fork to disappear completely
>>>
>>> -Stephen
>>>
>>>
>>> On 26 April 2013 03:22, Kenny Ayers  wrote:
>>>
 Hi folks,

 *Short Version:*
 *
 *
   I may have a fix for Jenkins-14551 (https://issues.jenkins-ci.**
 org/browse/JENKINS-14551).
   
 I've submitted this potential resolution to SVNKit as well as their 1.7.6 
 SVN branch has the same issue (http://issues.tmatesoft.com/**
 issue/SVNKIT-368 ). 
  I've compiled the change into the subversion-plugin on my test server, 
 and 
 the fix appears to work.

   Can a contributor peer review this change?

   How do I go about submitting this fix to the Jenkins SVNKit repo?  Do 
 I need a unit test before I can do a pull request?  The bug is obvious 
 when 
 you look at the code, and the unit test setup and execution seems like it 
 would be complicated.  I've forked the Jenkins SVNKit repo and committed 
 the modification here: https://github.com/**theotherwhitemeat/svnkit-1/
 **commit/**27decb28216ee4fd15b8fcbdb769bf**41d81978eb

 *Longer Version:*
 *
 *
   In org.tmatesoft.svn.core.**internal.wc.SVNUpdateEditor15.**java, in 
 function addFileWithHistory (line 867), there's a code block that calls 
 myFileFetcher.fetchFile() twice.  Each time this is called, baseTextOS is 
 written to.  Upon the second write, the file contents are duplicated. 
 Here's the code:


 baseTextOS = SVNFileUtil.**openFileForWriting(info.**copiedBaseText);
 myFileFetcher.fetchFile(**copyFromPath, copyFromRevision, baseTextOS, 
 baseProperties);
 SVNChecksumOutputStream checksumBaseTextOS = new 
 SVNChecksumOutputStream(**baseTextOS, 
 SVNChecksumOutputStream.MD5_**ALGORITHM, true);
 baseTextOS = checksumBaseTextOS;
  myFileFetcher.fetchFile(**copyFromPath, copyFromRevision, baseTextOS, 
 baseProperties);
 info.copiedBaseChecksum = checksumBaseTextOS.getDigest()**;



   I was able to find this by stepping through the code using NetBeans 
 IDE 7.3 attached to a remote debugging session on Jenkins.  I've compiled 
 and tested this change inside the context of the subversion-plugin and the 
 file contents are no longer duplicated.

   I've forked the svnkit repo used in Jenkins here, and committed this 
 change if anyone would like to download the fix and do some testing:

   https://github.com/**theotherwhitemeat/svnkit-1/**commit/**
 27decb28216ee4fd15b8fcbdb769bf**41d81978eb

   Here's my patch:

 Index: SVNUpdateEditor15.java
 ==**==**===
 --- SVNUpdateEditor15.java (revision 9722)
 +++ SVNUpdateEditor15.java (working copy)
 @@ -864,7 +864,6 @@
  OutputSt

Re: A possible fix for Jenkins-14551 - subversion-plugin duplicating file contents

2013-04-26 Thread Stephen Connolly
The process I usually follow is to beg KK to do the merge pleading that it
blew up in my face and there is no way he could do it during his
lunchbreak...

Though I may be using the "no way you could do that in your lunchbreak"
dare a bit too often... he may have wised up to my tricks... perhaps I need
to find a new one ;-)


On 26 April 2013 22:39, Kenny Ayers  wrote:

> Hey Stephen,
>
>   Alexander Kitaev from SVNKit has peer-reviewed this change and has
> rolled it into the upstream libraries, and the new binaries are available
> here:
> http://teamcity.tmatesoft.com/viewLog.html?buildId=6105&tab=artifacts&buildTypeId=bt43(
> http://issues.tmatesoft.com/issue/SVNKIT-368#comment=60-4930).  I'm not
> sure what the process is for getting this updated in the plugin, please let
> me know if there is anything else I can do to help.
>
> Thank you,
>
> Kenny
>
>
> On Friday, April 26, 2013 3:04:03 AM UTC-7, Stephen Connolly wrote:
>
>> Traditionally, the jenkins fork is maintaining a (hopefully) smaller set
>> of patches on top of the upstream version.
>>
>> The aim is to get the set of patches to zero and then drop the fork.
>>
>> With reference to the above aim, my preference would be to get it in
>> upstream rather than add to our current patch set.
>>
>> It is a real pain trying to update the code from upstream, at least every
>> time I have tried I have had to give up and get KK to do it (he has some
>> set of magic workspaces or something) so I would just love if we can get
>> the need for this fork to disappear completely
>>
>> -Stephen
>>
>>
>> On 26 April 2013 03:22, Kenny Ayers  wrote:
>>
>>> Hi folks,
>>>
>>> *Short Version:*
>>> *
>>> *
>>>   I may have a fix for Jenkins-14551 (https://issues.jenkins-ci.**
>>> org/browse/JENKINS-14551).
>>> I've submitted this potential resolution to SVNKit as well as their 1.7.6
>>> SVN branch has the same issue (http://issues.tmatesoft.com/**
>>> issue/SVNKIT-368 ).  I've
>>> compiled the change into the subversion-plugin on my test server, and the
>>> fix appears to work.
>>>
>>>   Can a contributor peer review this change?
>>>
>>>   How do I go about submitting this fix to the Jenkins SVNKit repo?  Do
>>> I need a unit test before I can do a pull request?  The bug is obvious when
>>> you look at the code, and the unit test setup and execution seems like it
>>> would be complicated.  I've forked the Jenkins SVNKit repo and committed
>>> the modification here: https://github.com/**theotherwhitemeat/svnkit-1/*
>>> *commit/**27decb28216ee4fd15b8fcbdb769bf**41d81978eb
>>>
>>> *Longer Version:*
>>> *
>>> *
>>>   In org.tmatesoft.svn.core.**internal.wc.SVNUpdateEditor15.**java, in
>>> function addFileWithHistory (line 867), there's a code block that calls
>>> myFileFetcher.fetchFile() twice.  Each time this is called, baseTextOS is
>>> written to.  Upon the second write, the file contents are duplicated.
>>> Here's the code:
>>>
>>>
>>> baseTextOS = SVNFileUtil.**openFileForWriting(info.**copiedBaseText);
>>> myFileFetcher.fetchFile(**copyFromPath, copyFromRevision, baseTextOS,
>>> baseProperties);
>>> SVNChecksumOutputStream checksumBaseTextOS = new SVNChecksumOutputStream(
>>> **baseTextOS,
>>> SVNChecksumOutputStream.MD5_**ALGORITHM, true);
>>> baseTextOS = checksumBaseTextOS;
>>> myFileFetcher.fetchFile(**copyFromPath, copyFromRevision, baseTextOS,
>>> baseProperties);
>>> info.copiedBaseChecksum = checksumBaseTextOS.getDigest()**;
>>>
>>>
>>>
>>>   I was able to find this by stepping through the code using NetBeans
>>> IDE 7.3 attached to a remote debugging session on Jenkins.  I've compiled
>>> and tested this change inside the context of the subversion-plugin and the
>>> file contents are no longer duplicated.
>>>
>>>   I've forked the svnkit repo used in Jenkins here, and committed this
>>> change if anyone would like to download the fix and do some testing:
>>>
>>>   https://github.com/**theotherwhitemeat/svnkit-1/**commit/**
>>> 27decb28216ee4fd15b8fcbdb769bf**41d81978eb
>>>
>>>   Here's my patch:
>>>
>>> Index: SVNUpdateEditor15.java
>>> ==**==**===
>>> --- SVNUpdateEditor15.java (revision 9722)
>>> +++ SVNUpdateEditor15.java (working copy)
>>> @@ -864,7 +864,6 @@
>>>  OutputStream baseTextOS = null;
>>>  try {
>>>  baseTextOS = SVNFileUtil.**openFileForWriting(info.**
>>> copiedBaseText);
>>> -myFileFetcher.fetchFile(**copyFromPath,
>>> copyFromRevision, baseTextOS, baseProperties);
>>>  SVNChecksumOutputStream checksumBaseTextOS = new
>>> SVNChecksumOutputStream(**baseTextOS,
>>>  SVNChecksumOutputStream.MD5_**ALGORITHM, 

Re: A possible fix for Jenkins-14551 - subversion-plugin duplicating file contents

2013-04-26 Thread Kenny Ayers
Hey Stephen,

  Alexander Kitaev from SVNKit has peer-reviewed this change and has rolled 
it into the upstream libraries, and the new binaries are available 
here: 
http://teamcity.tmatesoft.com/viewLog.html?buildId=6105&tab=artifacts&buildTypeId=bt43
 
(http://issues.tmatesoft.com/issue/SVNKIT-368#comment=60-4930).  I'm not 
sure what the process is for getting this updated in the plugin, please let 
me know if there is anything else I can do to help.

Thank you,

Kenny

On Friday, April 26, 2013 3:04:03 AM UTC-7, Stephen Connolly wrote:
>
> Traditionally, the jenkins fork is maintaining a (hopefully) smaller set 
> of patches on top of the upstream version.
>
> The aim is to get the set of patches to zero and then drop the fork.
>
> With reference to the above aim, my preference would be to get it in 
> upstream rather than add to our current patch set.
>
> It is a real pain trying to update the code from upstream, at least every 
> time I have tried I have had to give up and get KK to do it (he has some 
> set of magic workspaces or something) so I would just love if we can get 
> the need for this fork to disappear completely
>
> -Stephen
>
>
> On 26 April 2013 03:22, Kenny Ayers  >wrote:
>
>> Hi folks,
>>
>> *Short Version:*
>> *
>> *
>>   I may have a fix for Jenkins-14551 (
>> https://issues.jenkins-ci.org/browse/JENKINS-14551).  I've submitted 
>> this potential resolution to SVNKit as well as their 1.7.6 SVN branch has 
>> the same issue (http://issues.tmatesoft.com/issue/SVNKIT-368).  I've 
>> compiled the change into the subversion-plugin on my test server, and the 
>> fix appears to work.
>>
>>   Can a contributor peer review this change?
>>
>>   How do I go about submitting this fix to the Jenkins SVNKit repo?  Do I 
>> need a unit test before I can do a pull request?  The bug is obvious when 
>> you look at the code, and the unit test setup and execution seems like it 
>> would be complicated.  I've forked the Jenkins SVNKit repo and committed 
>> the modification here: 
>> https://github.com/theotherwhitemeat/svnkit-1/commit/27decb28216ee4fd15b8fcbdb769bf41d81978eb
>>
>> *Longer Version:*
>> *
>> *
>>   In org.tmatesoft.svn.core.internal.wc.SVNUpdateEditor15.java, in 
>> function addFileWithHistory (line 867), there's a code block that calls 
>> myFileFetcher.fetchFile() twice.  Each time this is called, baseTextOS is 
>> written to.  Upon the second write, the file contents are duplicated. 
>> Here's the code:
>>
>>
>> baseTextOS = SVNFileUtil.openFileForWriting(info.copiedBaseText);
>> myFileFetcher.fetchFile(copyFromPath, copyFromRevision, baseTextOS, 
>> baseProperties);
>> SVNChecksumOutputStream checksumBaseTextOS = new 
>> SVNChecksumOutputStream(baseTextOS, 
>> SVNChecksumOutputStream.MD5_ALGORITHM, true);
>> baseTextOS = checksumBaseTextOS;
>> myFileFetcher.fetchFile(copyFromPath, copyFromRevision, baseTextOS, 
>> baseProperties);
>> info.copiedBaseChecksum = checksumBaseTextOS.getDigest();
>>
>>
>>
>>   I was able to find this by stepping through the code using NetBeans IDE 
>> 7.3 attached to a remote debugging session on Jenkins.  I've compiled and 
>> tested this change inside the context of the subversion-plugin and the file 
>> contents are no longer duplicated.
>>
>>   I've forked the svnkit repo used in Jenkins here, and committed this 
>> change if anyone would like to download the fix and do some testing:
>>
>>   
>> https://github.com/theotherwhitemeat/svnkit-1/commit/27decb28216ee4fd15b8fcbdb769bf41d81978eb
>>
>>   Here's my patch:
>>
>> Index: SVNUpdateEditor15.java
>> ===
>> --- SVNUpdateEditor15.java (revision 9722)
>> +++ SVNUpdateEditor15.java (working copy)
>> @@ -864,7 +864,6 @@
>>  OutputStream baseTextOS = null;
>>  try {
>>  baseTextOS = 
>> SVNFileUtil.openFileForWriting(info.copiedBaseText);
>> -myFileFetcher.fetchFile(copyFromPath, copyFromRevision, 
>> baseTextOS, baseProperties);
>>  SVNChecksumOutputStream checksumBaseTextOS = new 
>> SVNChecksumOutputStream(baseTextOS, 
>>  SVNChecksumOutputStream.MD5_ALGORITHM, true);
>>  baseTextOS = checksumBaseTextOS;
>>
>> Thank you,
>>
>> Kenny Ayers
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-de...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: A possible fix for Jenkins-14551 - subversion-plugin duplicating file contents

2013-04-26 Thread Kenny Ayers
Hey Kutzi,

  It's helpful to step through the code to see the interaction.

  SVNUpdateEditor15 sees that a file is being added that contains file 
history.  baseTextOS is a bufferedOutputStream that is written to with the 
content of the previous version of the file during the first call to 
fetchFile(), here:

baseTextOS = 
SVNFileUtil.openFileForWriting(info.copiedBaseText);
myFileFetcher.fetchFile(copyFromPath, copyFromRevision, 
baseTextOS, baseProperties);

  At this point baseTextOS.buf contains "test line 1\n" (the contents of 
the original file).  Now a SVNChecksumOutputStream is instantiated with 
baseTextOS.  So checksumBaseTextOS.myTarget.buf contains "test line 1\n".

SVNChecksumOutputStream checksumBaseTextOS = new 
SVNChecksumOutputStream(baseTextOS, 
SVNChecksumOutputStream.MD5_ALGORITHM, true);

  Now baseTextOS is set to checksumBaseTextOS, and then fetchFile() is 
called once again.  After this call, checksumBaseTextOS.myTarget.buf 
contains "test line 1\n test line 1"
baseTextOS = checksumBaseTextOS;
myFileFetcher.fetchFile(copyFromPath, copyFromRevision, 
baseTextOS, baseProperties);

  The buffer contents are duplicated, and eventually written out to the 
file on disk.  Screenshots below of the step through.









  I hope this demonstrates the bug well enough.  Thank you again for your 
helping getting subversion-plugin to compile and for pointing me towards 
the Jenkins fork of SVNKit.  That was very helpful.

  It looks like the SVNKit folks were able to reproduce the issue and 
confirmed the modification I submitted appears to resolve the issue (please 
see the last comment here: http://issues.tmatesoft.com/issue/SVNKIT-368).

-Kenny

On Friday, April 26, 2013 12:54:26 AM UTC-7, kutzi wrote:
>
> Nice research. Good job.
> However, I'd like to wait whta the SVNkit developers say about it:
> The bug is not so obvious to me, as the value of baseTextOS, which seems 
> to be the ouptut file for fetchFile, changes between the 2 calls to 
> myFileFetcher.fetchFile()
> So the question is, why in your case both values seem to point to the same 
> file
>   
> *Gesendet:* Freitag, 26. April 2013 um 04:22 Uhr
> *Von:* "Kenny Ayers" >
> *An:* jenkin...@googlegroups.com 
> *Betreff:* A possible fix for Jenkins-14551 - subversion-plugin 
> duplicating file contents
> Hi folks, 
>  
> *Short Version:*
>  
>I may have a fix for Jenkins-14551 (
> https://issues.jenkins-ci.org/browse/JENKINS-14551).  I've submitted this 
> potential resolution to SVNKit as well as their 1.7.6 SVN branch has the 
> same issue (http://issues.tmatesoft.com/issue/SVNKIT-368).  I've compiled 
> the change into the subversion-plugin on my test server, and the fix 
> appears to work.
>  
>   Can a contributor peer review this change?
>  
>   How do I go about submitting this fix to the Jenkins SVNKit repo?  Do I 
> need a unit test before I can do a pull request?  The bug is obvious when 
> you look at the code, and the unit test setup and execution seems like it 
> would be complicated.  I've forked the Jenkins SVNKit repo and committed 
> the modification here: 
> https://github.com/theotherwhitemeat/svnkit-1/commit/27decb28216ee4fd15b8fcbdb769bf41d81978eb
>  
> *Longer Version:*
>  
>   In org.tmatesoft.svn.core.internal.wc.SVNUpdateEditor15.java, in 
> function addFileWithHistory (line 867), there's a code block that calls 
> myFileFetcher.fetchFile() twice.  Each time this is called, baseTextOS is 
> written to.  Upon the second write, the file contents are duplicated. 
> Here's the code:
>  
>  
>  
>  baseTextOS = SVNFileUtil.openFileForWriting(info.copiedBaseText);
>  myFileFetcher.fetchFile(copyFromPath, copyFromRevision, baseTextOS, 
> baseProperties);
>  SVNChecksumOutputStream checksumBaseTextOS = new 
> SVNChecksumOutputStream(baseTextOS, 
>  SVNChecksumOutputStream.MD5_ALGORITHM, true);
>  baseTextOS = checksumBaseTextOS;
>  myFileFetcher.fetchFile(copyFromPath, copyFromRevision, baseTextOS, 
> baseProperties);
>  info.copiedBaseChecksum = checksumBaseTextOS.getDigest();
>  
>   
>  
>   I was able to find this by stepping through the code using NetBeans IDE 
> 7.3 attached to a remote debugging session on Jenkins.  I've compiled and 
> tested this change inside the context of the subversion-plugin and the file 
> contents are no longer duplicated.
>  
>   I've forked the svnkit repo used in Jenkins here, and committed this 
> change if anyone would like to download the fix and d

Re: Missing maven-hpi-plugin-1.74 on BuildHive, central does not have it.

2013-04-26 Thread Jesse Glick
On Fri, Apr 26, 2013 at 4:03 PM, Mirko Friedenhagen
 wrote:
> the job is trying to get maven-hpi-plugin-1.74 from central and fails because 
> of this

Yes a bunch of BuildHive jobs for Jenkins plugins got broken recently
due to a change in Maven mirror handling. We are working on
determining the real cause and how to fix it.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: request for hosting new plugin

2013-04-26 Thread Ulli Hafner
Hi Tushar,

since I don't have admin privileges in GitHub I needed to create a new 
repository. But that seems not to work either. I don't know what's broken here. 
Now we have 3 repositories:
https://github.com/jenkinsci/rally-update-plugin-1 (this has already some 
commits, does this work for you?)
https://github.com/jenkinsci/rally-plugin (broken)
https://github.com/jenkinsci/rally-update-plugin (does not exist anymore?) 

Can someone with admin rights please remove the old broken repository and 
rename the first one?

Thanks, Ulli

Am 26.04.2013 um 10:45 schrieb Tushar Shinde :

> Could you please otherwise create another repository or fork it from here if  
> not able to resolve the commit access issue?
> 
> https://github.com/tushar686/rally-update-plugin
> 
> 
> On Wednesday, April 10, 2013 12:26:17 PM UTC+5:30, Tushar Shinde wrote:
> Hi, 
> 
> We have created a plugin for Jenkins that supports updating rally details 
> through Jenkins build and would like to see it hosted on jenkins-ci github. 
> 
> The name of the plugin is rallyupdate. Could you please create a repository 
> and assign me commit access?
> 
> GitHub ID  tushar686
> Jenkins JIRA account tushar686
> 
> Please let me know if you need any more information.
> 
> Kind regards, 
> Tushar Shinde 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Missing maven-hpi-plugin-1.74 on BuildHive, central does not have it.

2013-04-26 Thread Mirko Friedenhagen
Hello,

please take a look at
https://buildhive.cloudbees.com/job/jenkinsci/job/jswidgets-plugin/9/org.jenkins-ci.plugins$jswidgets/console

While the build itself  seems to succeed, a goal running afterwards
does not. It seems the job is trying to get maven-hpi-plugin-1.74 from
central and fails because of this.

This did happen after I updated the parent for my plugin to the latest
LTS-plugin-parent (1.480.3).

 I am puzzled.

Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: CI build set up for teamconcert-plugin

2013-04-26 Thread Scott Cowan
Can anyone explain how I can see the failing test logs?

https://buildhive.cloudbees.com/job/jenkinsci/job/teamconcert-plugin/3/console

Thanks,
Scott


On Thursday, April 11, 2013 5:49:09 AM UTC-4, Ullrich Hafner wrote:
>
> You can enable it on your own: 
>
> https://buildhive.cloudbees.com
>
> Ulli
>
>
> Am 11.04.2013 um 00:34 schrieb Scott Cowan 
> >:
>
> Could I have a CI build set up for teamconcert-plugin?
>
> The pom.xml is not at the root, but rather 
> com.ibm.team.build.hjplugin/pom.xml
>
>
> https://github.com/jenkinsci/teamconcert-plugin/blob/master/com.ibm.team.build.hjplugin/pom.xml
>
> Thanks a bunch!
> Scott
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-de...@googlegroups.com .
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Question on Jenkin

2013-04-26 Thread avineet
Hi,
We wanted to implement Jenkin in our project which require some kind of 
automation tool which support testing around Abnitio.
I have heard that Jenkin works with Abnitio,Could you please confirm me the 
same.
*What would be the Procurement cost of the product.
*
Also,I drafted few high level cases which we want the tool should 
support.Could anyone please have a look and let me know if these cases 
works with Jenkin.

Compare input and output record counts
Compare input values and output values
Validates transformations
Compares checksums created against the input and output (e.g. The sum 
of input column 1 = sum of output column 1)
Compare input with a filter record count with output record count
Supports files and tables as either the input or output (File to Table, 
Table to Table, Table to File)
Supports the validation of a test against a static value, e.g. Sum of 
column 1 = value x
Supports embedded SQL to use for the validation routine, e.g. Output of 
SQL 1 is equal to the output of SQL 2 or Output of SQL 1 is equal to this 

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: A possible fix for Jenkins-14551 - subversion-plugin duplicating file contents

2013-04-26 Thread Stephen Connolly
Traditionally, the jenkins fork is maintaining a (hopefully) smaller set of
patches on top of the upstream version.

The aim is to get the set of patches to zero and then drop the fork.

With reference to the above aim, my preference would be to get it in
upstream rather than add to our current patch set.

It is a real pain trying to update the code from upstream, at least every
time I have tried I have had to give up and get KK to do it (he has some
set of magic workspaces or something) so I would just love if we can get
the need for this fork to disappear completely

-Stephen


On 26 April 2013 03:22, Kenny Ayers  wrote:

> Hi folks,
>
> *Short Version:*
> *
> *
>   I may have a fix for Jenkins-14551 (
> https://issues.jenkins-ci.org/browse/JENKINS-14551).  I've submitted this
> potential resolution to SVNKit as well as their 1.7.6 SVN branch has the
> same issue (http://issues.tmatesoft.com/issue/SVNKIT-368).  I've compiled
> the change into the subversion-plugin on my test server, and the fix
> appears to work.
>
>   Can a contributor peer review this change?
>
>   How do I go about submitting this fix to the Jenkins SVNKit repo?  Do I
> need a unit test before I can do a pull request?  The bug is obvious when
> you look at the code, and the unit test setup and execution seems like it
> would be complicated.  I've forked the Jenkins SVNKit repo and committed
> the modification here:
> https://github.com/theotherwhitemeat/svnkit-1/commit/27decb28216ee4fd15b8fcbdb769bf41d81978eb
>
> *Longer Version:*
> *
> *
>   In org.tmatesoft.svn.core.internal.wc.SVNUpdateEditor15.java, in
> function addFileWithHistory (line 867), there's a code block that calls
> myFileFetcher.fetchFile() twice.  Each time this is called, baseTextOS is
> written to.  Upon the second write, the file contents are duplicated.
> Here's the code:
>
>
> baseTextOS = SVNFileUtil.openFileForWriting(info.copiedBaseText);
> myFileFetcher.fetchFile(copyFromPath, copyFromRevision, baseTextOS,
> baseProperties);
> SVNChecksumOutputStream checksumBaseTextOS = new
> SVNChecksumOutputStream(baseTextOS,
> SVNChecksumOutputStream.MD5_ALGORITHM, true);
> baseTextOS = checksumBaseTextOS;
> myFileFetcher.fetchFile(copyFromPath, copyFromRevision, baseTextOS,
> baseProperties);
> info.copiedBaseChecksum = checksumBaseTextOS.getDigest();
>
>
>
>   I was able to find this by stepping through the code using NetBeans IDE
> 7.3 attached to a remote debugging session on Jenkins.  I've compiled and
> tested this change inside the context of the subversion-plugin and the file
> contents are no longer duplicated.
>
>   I've forked the svnkit repo used in Jenkins here, and committed this
> change if anyone would like to download the fix and do some testing:
>
>
> https://github.com/theotherwhitemeat/svnkit-1/commit/27decb28216ee4fd15b8fcbdb769bf41d81978eb
>
>   Here's my patch:
>
> Index: SVNUpdateEditor15.java
> ===
> --- SVNUpdateEditor15.java (revision 9722)
> +++ SVNUpdateEditor15.java (working copy)
> @@ -864,7 +864,6 @@
>  OutputStream baseTextOS = null;
>  try {
>  baseTextOS =
> SVNFileUtil.openFileForWriting(info.copiedBaseText);
> -myFileFetcher.fetchFile(copyFromPath, copyFromRevision,
> baseTextOS, baseProperties);
>  SVNChecksumOutputStream checksumBaseTextOS = new
> SVNChecksumOutputStream(baseTextOS,
>  SVNChecksumOutputStream.MD5_ALGORITHM, true);
>  baseTextOS = checksumBaseTextOS;
>
> Thank you,
>
> Kenny Ayers
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




RE: Reload build.xml after finishing build

2013-04-26 Thread Sandell, Robert
The started by user is handled by the Cause of the build, in this case 
Cause.UserCause and is added to a CauseAction before the build starts.
A groovy script from the script console can change this by removing any 
existing causes in the action and adding a new.

I guess that a Groovy post build step could do the same.


Robert Sandell
Software Tools Engineer - SW Environment and Product Configuration
Sony Mobile Communications


> -Original Message-
> From: jenkinsci-dev@googlegroups.com [mailto:jenkinsci-
> d...@googlegroups.com] On Behalf Of mallikarjunece
> Sent: den 25 april 2013 11:59
> To: jenkinsci-dev@googlegroups.com
> Subject: Reload build.xml after finishing build
> 
> Hi,
> 
> I want to change the Started By User for the build.
> 
> How it is possible ?
> 
> Requirement is need to change build by user.
> 
> Quick reply appreciated.
> 
> Thanks in advance
> 
> 
> 
> --
> View this message in context:
> http://jenkins.361315.n4.nabble.com/Reload-build-xml-after-finishing-
> build-tp4664201.html
> Sent from the Jenkins dev mailing list archive at Nabble.com.
> 
> --
> You received this message because you are subscribed to the Google
> Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: request for hosting new plugin

2013-04-26 Thread Tushar Shinde
Could you please otherwise create another repository or fork it from here 
if  not able to resolve the commit access issue?

https://github.com/tushar686/rally-update-plugin


On Wednesday, April 10, 2013 12:26:17 PM UTC+5:30, Tushar Shinde wrote:
>
> Hi, 
>
> We have created a plugin for Jenkins that supports updating rally 
> detailsthrough Jenkins build and would like to see 
> it hosted on jenkins-ci github. 
>
> The name of the plugin is *rallyupdate*. Could you please create a 
> repository and assign me commit access?
>
> GitHub ID  *tushar686*
> Jenkins JIRA account tushar686
>
> Please let me know if you need any more information.
>
> Kind regards, 
> Tushar Shinde 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: New Jenkins Cors Plugin - request for commit access

2013-04-26 Thread Jochen Hinrichsen
Dear Ulli,

you can find the cors plugin here: 
https://github.com/jhinrichsen/cors-plugin

On Friday, 5 April 2013 09:44:31 UTC+2, Ullrich Hafner wrote:
>
> Typically we grant you access for your own plug-in only. Did you already 
> push your plugin to your github account already? Then we can fork it to our 
> organization? Or what should be the exact name of your plug-in that will be 
> used as git repository?
>
> Ulli
>
> Am 04.04.2013 um 20:28 schrieb Jochen Hinrichsen 
> 
> >:
>
> Dear folks,
>
> i would like to create the Cors plugin. Please allow commit access to 
> plugins repo.
>
> My github ID is jhinrichsen.
>
> Thanks in advance
>
> Jochen Hinrichsen
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-de...@googlegroups.com .
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Aw: A possible fix for Jenkins-14551 - subversion-plugin duplicating file contents

2013-04-26 Thread Christoph Kutzinski

Nice research. Good job.

However, I'd like to wait whta the SVNkit developers say about it:

The bug is not so obvious to me, as the value of baseTextOS, which seems to be the ouptut file for fetchFile, changes between the 2 calls to myFileFetcher.fetchFile()

So the question is, why in your case both values seem to point to the same file

 

Gesendet: Freitag, 26. April 2013 um 04:22 Uhr
Von: "Kenny Ayers" 
An: jenkinsci-dev@googlegroups.com
Betreff: A possible fix for Jenkins-14551 - subversion-plugin duplicating file contents

Hi folks,
 

Short Version:

 


  I may have a fix for Jenkins-14551 (https://issues.jenkins-ci.org/browse/JENKINS-14551).  I've submitted this potential resolution to SVNKit as well as their 1.7.6 SVN branch has the same issue (http://issues.tmatesoft.com/issue/SVNKIT-368).  I've compiled the change into the subversion-plugin on my test server, and the fix appears to work.

 

  Can a contributor peer review this change?

 

  How do I go about submitting this fix to the Jenkins SVNKit repo?  Do I need a unit test before I can do a pull request?  The bug is obvious when you look at the code, and the unit test setup and execution seems like it would be complicated.  I've forked the Jenkins SVNKit repo and committed the modification here: https://github.com/theotherwhitemeat/svnkit-1/commit/27decb28216ee4fd15b8fcbdb769bf41d81978eb

 

Longer Version:

 

  In org.tmatesoft.svn.core.internal.wc.SVNUpdateEditor15.java, in function addFileWithHistory (line 867), there's a code block that calls myFileFetcher.fetchFile() twice.  Each time this is called, baseTextOS is written to.  Upon the second write, the file contents are duplicated. Here's the code:

 

 




baseTextOS = SVNFileUtil.openFileForWriting(info.copiedBaseText);



myFileFetcher.fetchFile(copyFromPath, copyFromRevision, baseTextOS, baseProperties);



SVNChecksumOutputStream checksumBaseTextOS = new SVNChecksumOutputStream(baseTextOS, 



SVNChecksumOutputStream.MD5_ALGORITHM, true);



baseTextOS = checksumBaseTextOS;



myFileFetcher.fetchFile(copyFromPath, copyFromRevision, baseTextOS, baseProperties);



info.copiedBaseChecksum = checksumBaseTextOS.getDigest();




 

 

  I was able to find this by stepping through the code using NetBeans IDE 7.3 attached to a remote debugging session on Jenkins.  I've compiled and tested this change inside the context of the subversion-plugin and the file contents are no longer duplicated.

 

  I've forked the svnkit repo used in Jenkins here, and committed this change if anyone would like to download the fix and do some testing:

 

  https://github.com/theotherwhitemeat/svnkit-1/commit/27decb28216ee4fd15b8fcbdb769bf41d81978eb

 

  Here's my patch:

 

Index: SVNUpdateEditor15.java

===

--- SVNUpdateEditor15.java (revision 9722)

+++ SVNUpdateEditor15.java (working copy)

@@ -864,7 +864,6 @@

             OutputStream baseTextOS = null;

             try {

                 baseTextOS = SVNFileUtil.openFileForWriting(info.copiedBaseText);

-                myFileFetcher.fetchFile(copyFromPath, copyFromRevision, baseTextOS, baseProperties);

                 SVNChecksumOutputStream checksumBaseTextOS = new SVNChecksumOutputStream(baseTextOS, 

                         SVNChecksumOutputStream.MD5_ALGORITHM, true);

                 baseTextOS = checksumBaseTextOS;

 

Thank you,

 

Kenny Ayers


 
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 






-- 
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.