Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-5343

Incorrect client spec generated

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Reopened (View Workflow)
    • Priority: Trivial
    • Resolution: Unresolved
    • Component/s: perforce-plugin
    • Labels:
      None
    • Environment:
      Win XP Pro SP2, Hudson 1.341, Perforce Plugin 1.0.16
    • Similar Issues:

      Description

      The Perforce plugin now seems to append the "tail" of the depot path to the client root when auto-generating a client specification. Example:

      Client: foobar_cs
      View: //depot/projects/foobar/main/...

      When syncing, the following client spec view is generated (seen from build console):

      //depot/projects/foobar/main/... //foobar_cs/projects/foobar/main/...

      Previously (pre-1.0.16) the following was generated:

      //depot/projects/foobar/main/... //foobar_cs/...

      This behaviour causes all files within the project to end up under e.g. "C:\hudson-inst\jobs\foobar\workspace\projects\foobar\main".

        Attachments

          Activity

          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in hudson
          User: : rpetti
          Path:
          trunk/hudson/plugins/perforce/src/main/java/hudson/plugins/perforce/PerforceSCM.java
          trunk/hudson/plugins/perforce/src/main/webapp/help/project.html
          http://jenkins-ci.org/commit/28042
          Log:
          JENKINS-5343 reverting change made to view spec form validation in r27974, and adding a somewhat clearer description of what the RHS mapping is set to when it is ommitted.

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : rpetti Path: trunk/hudson/plugins/perforce/src/main/java/hudson/plugins/perforce/PerforceSCM.java trunk/hudson/plugins/perforce/src/main/webapp/help/project.html http://jenkins-ci.org/commit/28042 Log: JENKINS-5343 reverting change made to view spec form validation in r27974, and adding a somewhat clearer description of what the RHS mapping is set to when it is ommitted.
          Hide
          javadude Carl Quinn added a comment -

          Ah, I never used Hudson before last June and the 1.0.14 era of the Perforce plugin.

          Regarding the breaking of pre-1.0.14 users. Is there a way to know when we are reading a project from an old version? We could automatically expand the old single LHS entry into a single line pair which represents the functionality that use to be implied. That way we support pre-1.0.14 users, and still support the new functionality that I added in 1.0.16 (i think).

          Your point regarding the multiple depot case is a good one. But, in my experience I haven't seen an environment where there are a lot of depots, and I haven't yet seen a case where individual projects were split across depots. I suppose it could happen, and we shouldn't preclude it, but I don't think we need to optimize for it.

          So, I think adding the depot into the workspace path will be unnecessary most of the time. It will also break all of our Hudson jobs, and anyone else relying on the changes since 1.0.16. I would no longer be able to take advantage of this feature and would have to go and modify all of our jobs to specify the RHS. Maybe we could make the depot name inclusion a checkbox option?

          Show
          javadude Carl Quinn added a comment - Ah, I never used Hudson before last June and the 1.0.14 era of the Perforce plugin. Regarding the breaking of pre-1.0.14 users. Is there a way to know when we are reading a project from an old version? We could automatically expand the old single LHS entry into a single line pair which represents the functionality that use to be implied. That way we support pre-1.0.14 users, and still support the new functionality that I added in 1.0.16 (i think). Your point regarding the multiple depot case is a good one. But, in my experience I haven't seen an environment where there are a lot of depots, and I haven't yet seen a case where individual projects were split across depots. I suppose it could happen, and we shouldn't preclude it, but I don't think we need to optimize for it. So, I think adding the depot into the workspace path will be unnecessary most of the time. It will also break all of our Hudson jobs, and anyone else relying on the changes since 1.0.16. I would no longer be able to take advantage of this feature and would have to go and modify all of our jobs to specify the RHS. Maybe we could make the depot name inclusion a checkbox option?
          Hide
          javadude Carl Quinn added a comment -

          Another idea I had to handle different styles of project layout and RHS generation is to simply have 3 radio buttons to let the user select.

          Generate Workspace paths from:
          o Flattened depot paths
          o Straight depot paths
          o Straight paths with depot name

          Or, something like that but with better wording

          Show
          javadude Carl Quinn added a comment - Another idea I had to handle different styles of project layout and RHS generation is to simply have 3 radio buttons to let the user select. Generate Workspace paths from: o Flattened depot paths o Straight depot paths o Straight paths with depot name Or, something like that but with better wording
          Hide
          jnilsson jnilsson added a comment -

          I suggest moving this discussion to the user's list to allow more Perforce users to chime in. Some comments though:

          I agree that straight mapping, between the a specific project in the depot and the workspace, is the preferred way to go. I mentioned the possibility of mapping dependencies into separate subdirectories of the main project using the client spec, not because I would recommend that, but because it is virtually the same thing as the "auto-mapping" currently employed + that it IMVHO makes it easier to identify them as dependencies of the main project. Having them at an equal level in the directory tree suggests that they are of equal importance. But that's just a matter of preference I guess.

          Generally though, mapping dependencies using a client spec looks a bit brittle to me; anything in the "main" project's dependencies can change under your feet at each sync, causing incompatibility either implementation-wise or interface-wise. Our preferred approach is to branch the dependencies at known versions into a specific subdirectory of the main project and then keep the view/workspace mapping to a single line.

          Show
          jnilsson jnilsson added a comment - I suggest moving this discussion to the user's list to allow more Perforce users to chime in. Some comments though: I agree that straight mapping, between the a specific project in the depot and the workspace, is the preferred way to go. I mentioned the possibility of mapping dependencies into separate subdirectories of the main project using the client spec, not because I would recommend that, but because it is virtually the same thing as the "auto-mapping" currently employed + that it IMVHO makes it easier to identify them as dependencies of the main project. Having them at an equal level in the directory tree suggests that they are of equal importance. But that's just a matter of preference I guess. Generally though, mapping dependencies using a client spec looks a bit brittle to me; anything in the "main" project's dependencies can change under your feet at each sync, causing incompatibility either implementation-wise or interface-wise. Our preferred approach is to branch the dependencies at known versions into a specific subdirectory of the main project and then keep the view/workspace mapping to a single line.
          Hide
          rpetti Rob Petti added a comment -

          The radio buttons idea sounds good to me. I'll take a look at implementing it this weekend if I'm not doing anything.

          As a side note, my company has 28 separate depots in our perforce server, so that's why I brought up the depot names issue.

          Show
          rpetti Rob Petti added a comment - The radio buttons idea sounds good to me. I'll take a look at implementing it this weekend if I'm not doing anything. As a side note, my company has 28 separate depots in our perforce server, so that's why I brought up the depot names issue.

            People

            • Assignee:
              Unassigned
              Reporter:
              jnilsson jnilsson
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: