|
||||||||
|
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 jenkinsci-issues+unsubscr...@googlegroups.com.
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