[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
[ http://jira.codehaus.org/browse/SCM-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102719 ] Dana Lacoste commented on SCM-258: -- I haven't investigated the code since November 2006, but at that time, Brian, but at that time this would happen : 1 - read filespec line 2 - create new clientspec with filespec line as referenced (over-write, not append) 3 - sync 4 - if not persist, delete clientspec. if persist, keep clientspec. so you always lost your current clientspec, though you could keep it for manual work later. It's just the way the code was written. the persist variable was not investigated at clientspec create, only at clientspec delete. > 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: http://jira.codehaus.org/browse/SCM-258 > 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 > Fix For: future > > > One of the strengths of perforce is the ability to do fairly complex actions > with the clientspec. > 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:[EMAIL > PROTECTED]:port:@clientspec_name > (the second @ being a placeholder for a delimiter) > - As an environment variable (perhaps the existing > maven.scm.perforce.clientspec.name, > 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 situation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-257) The perforce provider should provide an "update" functionality for the SCM plugin's "update" command that is semantically correct.
The perforce provider should provide an "update" functionality for the SCM
plugin's "update" command that is semantically correct.
--
Key: SCM-257
URL: http://jira.codehaus.org/browse/SCM-257
Project: Maven SCM
Issue Type: Improvement
Components: maven-scm-provider-perforce
Environment: All OS, maven 2.x SCM plugin linked to perforce
Reporter: Dana Lacoste
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-258) The perforce provider should be able to accept complex filespecs using a clientspec rather than the path in the SCM url
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: http://jira.codehaus.org/browse/SCM-258 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 clientspec. 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:[EMAIL PROTECTED]:port:@clientspec_name (the second @ being a placeholder for a delimiter) - As an environment variable (perhaps the existing maven.scm.perforce.clientspec.name, 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 situation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-257) The perforce provider should provide an "update" functionality for the SCM plugin's "update" command that is semantically correct.
[ http://jira.codehaus.org/browse/SCM-257?page=comments#action_81936 ]
Dana Lacoste commented on SCM-257:
--
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= 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.
> The perforce provider should provide an "update" functionality for the SCM
> plugin's "update" command that is semantically correct.
> --
>
> Key: SCM-257
> URL: http://jira.codehaus.org/browse/SCM-257
> Project: Maven SCM
> Issue Type: Improvement
> Components: maven-scm-provider-perforce
> Environment: All OS, maven 2.x SCM plugin linked to perforce
>Reporter: Dana Lacoste
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[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
[ http://jira.codehaus.org/browse/SCM-258?page=comments#action_81937 ]
Dana Lacoste commented on SCM-258:
--
Unfortunately, the same problem as in the other issue occurs:
update and checkout are the same, and they both (in the first try {} block of
executeCheckoutCommand()) overwrite the existing clientspec with the fileset
information provided in the SCM URL
> 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: http://jira.codehaus.org/browse/SCM-258
> 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 clientspec.
> 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:[EMAIL
> PROTECTED]:port:@clientspec_name
> (the second @ being a placeholder for a delimiter)
> - As an environment variable (perhaps the existing
> maven.scm.perforce.clientspec.name,
> 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 situation.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
