|
History
| Log In
|
|
|
|
I can't get svn diff to work....it can't find the source file when I point it at the tagged version, and when I try to specify the revision (?rev=...) it complains about the URL formatting.
Ok...ignore my last comment. I should RTFM first
 Please note that this diff contains fixes for this bug as well as This patch fails when running the changelog command in standalone mode. Use the SCM plugin to run a changelog on some directory "mvn scm:changelog -DconnectionUrl=XXX" where XXX is your developerConnection string in the POM and you will find that the command fails due to the clientspec not existing. This is because your patch assumes it is always run after an update.
Nonetheless, I'm inclined to think this is better than before since Continuum is the major user of the changelog command and it wasn't working for Continuum before. I'm assuming that most people don't use the SCM plugin except for testing. Emmanuel, do you have any opinion here? Would you rather see the changelog command only work as part of an update/checkout or not work with those but work standalone? Would it be acceptable for me to set the clientspec in use as a system property or static variable and the changelog command would do the following?
if (clientspec preset) Can I assume that the update/checkout and changelog commands are run as part of a single VM invocation? changelog command must work in standalone mode (require by changelog mojo and by changelog report mojo) AND as part of update command (require by update mojo and continuum).
update and changelog commands doesn't run necessarily as part of a single VM invocation.
I don't see how I can make this work in all cases without forcing the user to provide a parameter or use something like the release.properties file that the release plugin uses. I will brainstorm tonight and come up with the best compromise I can.
Here's my understanding of the requirements:
1) Continuum needs to be able to run update/checkout and changelog in the same VM when running a build. Since this uses a persistent clientspec, the changelog command needs to reuse the same clientspec. That's what this bug is about and it should work with my changes 3 days ago. Any comments? Any other usecases? Posted a release candidate with my small changes to allow these usecases. I'm still afraid there will be edge cases I've missed - Emmanuel, can you point me to the changelog plugin and the documentation on how to use it so I can test it here?
Mike, we have 2 changelog plugins:
This still breaks in continuum. Here's the problem: continuum may update many different projects within the same VM. If it is always updating the working directory on the client spec to a different directory, then every time the checkout command is executed perforce returns the entire set of source files. This means continuum will build the project every single time, even if no changes have occurred. Here's an example:
1. Project 1's home is in /home/continuum/1 Suggested fix: Another fix would be to maintain a map of working directory to clientspec, but I'm not sure where exactly you'd store this. Oops..replace "change log command" with "checkout command" in steps 4, 6, 7 above.
John, I updated the changelog command as you mentioned. There is a "maven.scm.persistcheckout" system property (see also ScmProviderRepository.setPersistCheckout()) which will persist the clientspec across invocations. Feel free to test this change and reopen if you find still have problems.
I've found a problem related to system property approach which appears in continuum, I've filed it as C's issue CONTINUUM-1183. But it's an scm bug and I think it should be fixed in the scope of this issue.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Critical
PerforceChangeLogCommand needs to use the same clientspec as the update command
svn diff > patch.diff