PerforceChangeLogCommand needs to use the same clientspec as the update command

John, please attach a standard SVN diff. Your diff does not contain the filename headers.

svn diff > patch.diff

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 SCM-168.

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)
{
use that clientspec
}
else
{
default to no clientspec
}

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.
2) The changelog mojo needs to be able to run the changelog command as a standalone feature. The command should default to NO clientspec but allow the user to pass in a clientspec on the command line.
3) The user should be able to run 'mvn scm:update scm:changelog' to get results similar to (1) and 'mvn scm:changelog' to get results similar to (2).

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:

• in maven-scm plugin that can be use for test
• in mojo project, this plugin generate changelog reports and doc are online

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
2. Project 2's home is in /home/continuum/2
3. Continuum builds project 1
4. change log command creates clientspec foobar1
5. Continuum builds project 2
6. change log command uses default clientspec foobar1
7. change log command sets working directory to /home/continuum/2
8. Perforce interprets this as "the client has switched to a new working directory, and I have no idea what state the files in that directory are in, so I'm going to check out everything"
9. Change list is generated, even though no files are changed
10. Continuum proceeds to build project 2

Suggested fix:
1. Use a system property to determine whether or not to store clientspecs for future use. Default to true.
2. Change PerforceChangeLogCommand to use PerforceScmProvider.getClientSpecName(). That way, it will generate the same clientspec used by the checkout command for the same working directory.

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.