maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Perham (JIRA)" <>
Subject [jira] Commented: (SCM-258) The perforce provider should be able to accept complex filespecs using a clientspec rather than the path in the SCM url
Date Sat, 02 Dec 2006 07:28:41 GMT
    [ ] 
Mike Perham commented on SCM-258:

Dana, I don't believe the Perforce provider will ever provide easy, ad hoc SCM operations.
 The semantics are just too far removed from what CVS/SVN provide (and the SCM API assumes).

You should be able to set up a clientspec by hand and then use 'mvn<clientspec-name>
scm:checkout' to check out the contents of that clientspec to the current directory.  Note
the checkout command will update the clientspec to change the Root to the current directory.

See SCM-110 for details on force syncing.

If this is sufficient for your needs, please let me know so I can close this issue.

> The perforce provider should be able to accept complex filespecs using a clientspec rather
than the path in the SCM url
> -----------------------------------------------------------------------------------------------------------------------
>                 Key: SCM-258
>                 URL:
>             Project: Maven SCM
>          Issue Type: Improvement
>          Components: maven-scm-provider-perforce
>         Environment: All OS, Maven 2.x using the SCM plugin to talk to perforce
>            Reporter: Dana Lacoste
> One of the strengths of perforce is the ability to do fairly complex actions with the
> For example:
> 1 - Checkout two file structures into one location:
>     //depot1/tree1/...  //client/project/tree1
>     //depot2/tree2/...  //client/project/tree2
> 2 - Rename file structures at checkout time :
>     //depot/tree/sample-configuration.xml  //client/tree/configuration.xml
> The SCM URL format doesn't allow this (and implementing it would be difficult)
> Currently, the perforce provider doesn't seem to allow a way to use an existing clientspec
(all codepaths seem to create a new clientspec based on the URL)
> If the provider could allow an existing clientspec to define the file structure, this
functionality could be enabled.
> Testing:
> I don't have any JUnit experience, but I think this could be tested by:
> 1 - Create a clientspec that defines some complex content, for example:
>     //depot/project/src/...   //clientspec/project/src/...
>     //ThirdParty/...  //clientspec/project/ThirdParty/...
> 2 - run "mvn scm:checkout" and all files should be checked out.
> Implementation Ideas:
> I can see multiple ways of doing this, depending on the restrictions/conventions required
> A - Use the existing "bootstrap/target/checkout" dynamic directory structure
>       - Using "p4 client -o" with the given/predefined/assumed clientspec, alter the
p4_root  (the line containing "Root:") and do a "p4 sync -f"
>        (Definition of the clientspec ideas defined separately below)
> B - Assume the clientspec has a defined "Root:" and use that for the purposes of "locating"
files (needed for tag/editing/checkin purposes)
>     - As I'm only checking out, I really don't know how this would affect a checkin :)
> C - Separate from above, how to define which clientspec to use:
>     - In the SCM URL, perhaps with scm:perforce:[username@]host:port:@clientspec_name
>       (the second @ being a placeholder for a delimiter)
>     - As an environment variable (perhaps the existing,
>       enabling this functionality (re-use vs. re-create) with a different property
>     - Defined in the settings.xml or in the pom.xml in the SCM configuration properties
> I'm sure more details will be required, this is only what I've identified within my particular

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message