We are using perforce, but I am not putting this against it, because I hope it will work consistently across all providers.

Its confusing exactly which scenarios are supported by the maven plugin. It seems to work great with the release plugin, but using the scm plugin directly is not straightforward.

There is probably only a handful of reasons people will be using the scm plugin directly, rather than part of something like the release plugin, these include.

1) scm:update or scm:status - to sync or check an existing checkout against HEAD or label. i.e. cruisecontrol.

• in perforce this would use an existing clientspec.
  2) scm:checkout - to get a new working directory that then supports scm:status, scm:update etc
• in perforce this would be a new persistent clientspec.
  3) export files from source control e.g. "cvs export",
• in perforce this would be a new temporary clientspec.

In terms of the direction of the project, the use of system properties seems a bit brittle as these providers might be used multiple times within a mvn build. i.e. the release plugin, checks the local status 1), then does a clean checkout 3). Although I guess the release plugin might just set these option in code anyway, ignoring the system property.

Examples of the problems we are having, scm:checkout works well, but then trying to use scm:update gives you wrong results. Without the page showing the typical use cases of the scm plugin (regardless of SCM provider), its hard to work out if something is a bug or just not supported.