|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
@Scott,
This may be specific to my project, but I'm using a custom workspace for my project (E:\Work\Jenkins\<ModuleName>) and have left the "Legacy mode" checkbox unchecked and this seems to work for me.
@Michael
You mention branching 1.6 and applying retrospective changes but there is another option.
The reason both Scott and I have been forced into messing around with version 1.6 of the plug-in is described in https://issues.jenkins-ci.org/browse/JENKINS-18330; basically the current version doesn't support :sspi:, and doesn't provide a mechanism to use an external program to implement the :ext: protocol in the way that Netbeans itself does. It seems to only support :ext: using the built-in facilities (SSH) of the Netbeans-like client.
A better option for me (and I suspect Scott and the few others who've been struggling with this issue on the Jenkins forum) would be to modify the current CVS plug-in to allow an option to use either the built-in facilities or an external program. Given that 1.6 forced the use of an external program I would assume that, once the output from the CVS commands (either from within the plug-in or from the external program) is captured then the processing would be fairly common.
I imagine this would be a much simpler option than branching 1.6 and having separate versions of the plug-in.
Does this sound feasible?
John