Changes to the perforce plugin

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Changes to the perforce plugin

Tim Hepner

https://hudson.dev.java.net/issues/show_bug.cgi?id=1745

https://hudson.dev.java.net/issues/show_bug.cgi?id=1746

 

I’ve submitted some issues for the perforce plugin.  If there are no objections I’d like to start working on them.  The 1st issue is minor.  The 2nd is critical for distributed builds. 

 

Mike and Victor (and whoever else is interested) can you look the issues over and make I’m not missing something here.  Let me know if I need to clarify anything.

            Thanks,

                        Tim   

Reply | Threaded
Open this post in threaded view
|

Re: Changes to the perforce plugin

digerata-3
Tim, in regards to 1745, did you see my post from bug 1656?  I originally supported this idea but was confusing it with a matrix project scenario. 

In non master/slave usage, the plugin is not responsible for creating a new clientspec.  It only uses whatever is specified by the end user.  In a master/slave scenario, I would expect the same functionality.  I believe that most Perforce administrators would prefer to be in control of creating new objects (clientspec or otherwise) on their system.  We shouldn't traverse into their territory, especially when the time savings for creating new clientspecs is negligible.  Additionally, as you allude too, the error handling and possibility of incorrect usage, such as clientspec name, could add a significant amount of code.

As for 1746, I agree that while the chances are slim, the possibility exists so we should guard against it.  Please feel free to implement this.

Thanks,

-Mike

On May 23, 2008, at 11:57 AM, Victor Szoltysek wrote:

Concerning 1745,
 
Personally I think it will just add unnecessary complexity to the plug-in, for a feature that the vast majority of users will not need.
 
My understanding of P4 common practices, is that client specs are meant to be tied to individual machines. Users can just create new ones for each new machine added to P4.
 
 
-Vic
 


From: Tim Hepner [[hidden email]] 
Sent: Thursday, May 22, 2008 2:36 PM
To: [hidden email]
Cc: [hidden email]; [hidden email]
Subject: Changes to the perforce plugin

 
I’ve submitted some issues for the perforce plugin.  If there are no objections I’d like to start working on them.  The 1st issue is minor.  The 2nd is critical for distributed builds. 
 
Mike and Victor (and whoever else is interested) can you look the issues over and make I’m not missing something here.  Let me know if I need to clarify anything.
            Thanks,
                        Tim   

Reply | Threaded
Open this post in threaded view
|

RE: Re: Changes to the perforce plugin

Tim Hepner

The change I’m proposing will have no affect on builds that run only on the master.  I only want a new client spec to be created if the build is running on a slave. 

 

Currently the distributed builds feature of Hudson is broken.  This is probably the most attractive feature Hudson has to offer.

 

I’ve implemented a prototype and the change is actually very small.  All I had to do was append something to the end of the client for each slave.  Because of the way you’re currently modifying the view, slaves are automatically created with no additional configuration necessary.

 

I understand your concerns about perforce administration and error handling.  I think we need to be careful in both these areas.  For the clientspec naming problem I think we should use the hostname of the slave.  I haven’t found a set of rules yet that list the allowable characters in a clientspec name but I imagine that rules to for a hostname are similar. 

 

As far as perforce administration goes people are generally allowed to create as many clientspecs as they need (at least where I work they are).  I think there will be some concern about them being created automatically.  We will need to be very clear about this in the help. 

 

Thanks,

            Tim

 

 


From: K. Michael Wille [mailto:[hidden email]]
Sent: Friday, May 23, 2008 10:17 AM
To: Victor Szoltysek
Cc: Tim Hepner; [hidden email]; [hidden email]
Subject: Re: Changes to the perforce plugin

 

Tim, in regards to 1745, did you see my post from bug 1656?  I originally supported this idea but was confusing it with a matrix project scenario. 

 

In non master/slave usage, the plugin is not responsible for creating a new clientspec.  It only uses whatever is specified by the end user.  In a master/slave scenario, I would expect the same functionality.  I believe that most Perforce administrators would prefer to be in control of creating new objects (clientspec or otherwise) on their system.  We shouldn't traverse into their territory, especially when the time savings for creating new clientspecs is negligible.  Additionally, as you allude too, the error handling and possibility of incorrect usage, such as clientspec name, could add a significant amount of code.

 

As for 1746, I agree that while the chances are slim, the possibility exists so we should guard against it.  Please feel free to implement this.

 

Thanks,

 

-Mike

 

On May 23, 2008, at 11:57 AM, Victor Szoltysek wrote:



Concerning 1745,

 

Personally I think it will just add unnecessary complexity to the plug-in, for a feature that the vast majority of users will not need.

 

My understanding of P4 common practices, is that client specs are meant to be tied to individual machines. Users can just create new ones for each new machine added to P4.

 

 

-Vic

 

 


From: Tim Hepner [[hidden email]] 
Sent: Thursday, May 22, 2008 2:36 PM
To: [hidden email]
Cc: [hidden email]; [hidden email]
Subject: Changes to the perforce plugin

 

Ive submitted some issues for the perforce plugin.  If there are no objections Id like to start working on them.  The 1st issue is minor.  The 2nd is critical for distributed builds. 

 

Mike and Victor (and whoever else is interested) can you look the issues over and make Im not missing something here.  Let me know if I need to clarify anything.

            Thanks,

                        Tim