Jump to content

wyattetal

Members
  • Content Count

    38
  • Joined

  • Last visited

  • Days Won

    1

wyattetal last won the day on January 27

wyattetal had the most liked content!

Community Reputation

1 Neutral

About wyattetal

  • Rank
    Advanced Member

Recent Profile Visitors

1,692 profile views
  1. Is there a command line call to determine the changeset of the xlinked repo within a workspace? If not, is there an API available for writing a tool to do so? Example: Repo Blue has an x-link to Repo Red. I create a workspace for Repo Blue, which pulls down the contents of Repo Red as well. I cd to a directory within Red's hierarchy and call "cm status" The result is cs:<CHANGESET OF BLUE>@Blue@ ... (head) What I want to query is the changeset of Red. (The repo xlinked by Blue)
  2. Thanks. Can you explain what changes result in the differing output? In other words, what should I do to a workspace order to force the alternate formats of cm status --nochanges?
  3. We recently discovered that the output of cm status is variable based on the state of the workspace. This affects windows batch scripted calls that parse the output for the changeset version. How do we call cm (or other command line tool) to get the current changeset in a consistent manner? First format example: cm status --nochanges ==> cs:1002@<REPO>@ssl://<PLASTIC SERVER>:8088 (head) Second Format example: cm status --nochanges /main/JIRA_TASK@<REPO>@ssl://<PLASTIC SERVER> (cs:1627 - head) Alternatively, what windows batch script code do you recommend to extract the changset number that will work for these and any other format variations? Thanks.
  4. The setup: Project A and Project B both use the plastic plug-in and both of these jenkins projects have the same workspace directory name. When project B builds, project A's workspace directory is deleted. Project B's log will indicate that the workspace directory within projectA's jenkins folder was deleted early in the build. It might look like this: Started by an SCM change Building in workspace C:\JenkinsBuilds\ProjectB\workspace [oneforall] $ "C:\Program Files\PlasticSCM5\client\cm" lwk --format={0}#{1}#{2} oneforall#ENGBLD#c:\JenkinsBuilds\ProjectA\workspace\oneforall [oneforall] $ "C:\Program Files\PlasticSCM5\client\cm" rmwk wk:oneforall The workspace oneforall has been deleted. FATAL: c:\JenkinsBuilds\ProjectA\workspace\oneforall\.plastic\plastic.lck: The process cannot access the file because it is being used by another process. ERROR: null Finished: FAILURE or this: Started by an SCM change Building in workspace C:\JenkinsBuilds\ProjectB\workspace [oneforall] $ "C:\Program Files\PlasticSCM5\client\cm" lwk --format={0}#{1}#{2} oneforall#ENGBLD#c:\JenkinsBuilds\ProjectA\workspace\oneforall [oneforall] $ "C:\Program Files\PlasticSCM5\client\cm" rmwk wk:oneforall The workspace oneforall has been deleted. [oneforall] $ "C:\Program Files\PlasticSCM5\client\cm" mkwk oneforall . --selector=selector7411337582865039699.txt Workspace oneforall has been correctly created [oneforall] $ "C:\Program Files\PlasticSCM5\client\cm" update . Searching for changed items in the workspace... Project A's next change poll looks like this: >>>(is it also a bug that the plug-in determines that changes are present when wi returns EC 1? )<<< Started on May 26, 2016 6:56:00 AM Polling SCM changes on master [PlasticPull] $ "C:\Program Files\PlasticSCM5\client\cm" wi --machinereadable --fieldseparator=def#_#sep c:\JenkinsBuilds\PROJECTA\workspace\PlasticPull is not in a workspace. FATAL: Executable returned an unexpected result code [1] ERROR: PlasticPull: Unable to retrieve workspace status. hudson.AbortException at com.codicesoftware.plugins.hudson.PlasticTool.execute(PlasticTool.java:89) at com.codicesoftware.plugins.hudson.model.Server.execute(Server.java:31) at com.codicesoftware.plugins.hudson.model.Server.getChangesets(Server.java:42) at com.codicesoftware.plugins.hudson.model.Server.getBriefHistory(Server.java:122) at com.codicesoftware.plugins.hudson.PlasticSCM.HasChanges(PlasticSCM.java:349) at com.codicesoftware.plugins.hudson.PlasticSCM.compareRemoteRevisionWith(PlasticSCM.java:162) at hudson.scm.SCM.poll(SCM.java:398) at hudson.model.AbstractProject.pollWithWorkspace(AbstractProject.java:1468) at hudson.model.AbstractProject._poll(AbstractProject.java:1438) at hudson.model.AbstractProject.poll(AbstractProject.java:1349) at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:526) at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:555) at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:119) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Done. Took 2 sec Changes found The implication is that the Plastic plug-in is somehow maintaining state between invocations and then interacts badly with duplicated workspace names. At first blush, the problem appears to be that the plugin is deleting workspaces even though "Use Update" is checked. Changing A & B to have unique names works around the issue.
  5. Frequently (but not always) when I compile in VS2015 (and sometimes just when VS2015 gets focus), I get a dialog that reports: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. Server <our server>:8088. An existing connection was forcibly closed by the remote host. Some details: * The source control plug-in (Tools->Options->Source Control) is set to Plastic SCM. * My plastic configuration does not use port 8088. It uses 8087. It is unclear why the dialog is citing port 8088. * I am running two instances of VS2015, each looking at a solution in a different repo & workspace from the other. * In one of the workspaces/solutions, some (but not all) vcxproj's have the SCC section set to plastic plug-in. * Uninstalling the plastic plug-in eliminates the dialogs. * Uninstalling the plastic SCM plug-in from VS2015 causes VS2015 to modify the SCC sections of the above noted projects to remove the plug-in info. (So as a team we apparently need to all use the plug-in or none of us use it). In general, it is not clear to me if the Plastic SCM plug-in is intended to be: * A VS2015 choice; in which case why note and enforce via the vcxproj file? * A project choice; in which case I do not understand how to specify for all rather than some of a vcxproj's in a repo.
×
×
  • Create New...