On Fri, 2005-05-13 at 17:54 -0500, Mike Esler wrote: > I've been looking at the ScmWagon source, and think it does a really > good job of illustrating where the SCM API can be improved. > > First, in lines 154-173, you're basically attempting to "import" a > project or create a "sandbox", or if it already exists to "update" or > "resync". There's a special check for .svn and CVS folders. > > The following block (lines 176-190) show the complexity of adding a > file. In this case, you need to call both "add" and "checkin". For many > version control systems, "add" would be sufficient. > > What do you think about refactoring around use-cases, instead of > commands? > - Import Project > - Drop Project > - Resync Project > - Add FileSet > - Drop FileSeet > - Update FileSet > - Get FileSet Status > - Get FileSet Changelog > > These would be the new ScmManager methods. We would eliminate the > DefaultScmManager, and then require every provider to implement an > ScmManager.
These ideas look good, but we probably implement them at the provider level and just get rid of the ScmManager which is the entity which currently holds references to all active Maven SCM providers. We chatted briefly in IRC but I think we're going to model Maven SCM after Maven Wagon where we focus on the providers. In our case the providers for each individual SCM. Then if we need tools to help manage a set of providers we can do that in a separate build. But in Maven SCM proper we would like to focus on the providers. > This seems like a relatively low impact refactor since the provider > implementations of the commands remain unchanged. > > Cheers, > Mike Esler > -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org Three people can keep a secret provided two of them are dead. -- Unknown
