Maven SCM
  1. Maven SCM
  2. SCM-257

The perforce provider should provide an "update" functionality for the SCM plugin's "update" command that is semantically correct.

    Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: future
    • Labels:
      None
    • Environment:
      All OS, maven 2.x SCM plugin linked to perforce
    • Complexity:
      Intermediate
    • Number of attachments :
      0

      Description

      The perforce provider implements the update command as a checkout.

      This is not semantically correct in the following situations:

      1 - If no changes are pending, the update command should not do anything
      2 - If some files are changed, only those files should be updated.

      (The checkout command checks out all files, regardless of what already exists)

      This is particularly daunting if (in my case there is a very large directory structure in perforce that does not change regularly (checking out a 4GB fileset that hasn't changed is, effectively, wasted time.)

      (As this is my first time using JIRA feel free to correct any of the settings I've made)

      Testing info:

      Although I don't have any JUnit experience, a test case can be made simply:

      1 - create a perforce repository with two files in it (and configure maven to use it)
      2 - run "mvn scm:checkout" to obtain the files
      3 - modify one of the files on another system, check the modified file into perforce
      4 - run "mvn scm:update" and only the modified file should be checked out.

      Implementation Ideas:

      Somehow the "scm:update" command will need to know that the files already exist. The most simple way is to require that $

      {P4CLIENT}

      be set and simply to run "p4 sync ..." in the directory involved (or, similarly, "p4 sync $

      {path}

      ..." using the path that's defined in the scm URL) and to allow perforce to do the work of figuring out what's needed.

        Activity

        Hide
        Mike Perham added a comment -

        mvn -Dmaven.persist.checkout=true -Dmaven.scm.perforce.clientspec.name=<clientspec-name> scm:update

        This will sync the contents of that clientspec to the current directory. If the current directory is empty, it will force sync. The persistcheckout flag ensures that the command will not delete the clientspec when the command is complete (as it does by default).

        Show
        Mike Perham added a comment - mvn -Dmaven.persist.checkout=true -Dmaven.scm.perforce.clientspec.name=<clientspec-name> scm:update This will sync the contents of that clientspec to the current directory. If the current directory is empty, it will force sync. The persistcheckout flag ensures that the command will not delete the clientspec when the command is complete (as it does by default).
        Hide
        Dana Lacoste added a comment -

        Although persist.checkout will work for keeping a clientspec persistent (after the checkout command runs), it won't allow for using an existing clientspec in that same checkout command.

        In other words, if I want to use a clientspec that's already defined, maven.scm.perforce.clientspec.name=<clientspec-name> will definitely work, but executeCheckOutCommand() will (in the first try {} block) delete that clientspec with its "p4 client -i" command.

        So the test fails at step 4 above.

        Show
        Dana Lacoste added a comment - Although persist.checkout will work for keeping a clientspec persistent (after the checkout command runs), it won't allow for using an existing clientspec in that same checkout command. In other words, if I want to use a clientspec that's already defined, maven.scm.perforce.clientspec.name=<clientspec-name> will definitely work, but executeCheckOutCommand() will (in the first try {} block) delete that clientspec with its "p4 client -i" command. So the test fails at step 4 above.

          People

          • Assignee:
            Unassigned
            Reporter:
            Dana Lacoste
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: