You are viewing a plain text version of this content. The canonical link for it is here.
Posted to scm-dev@maven.apache.org by Mike Esler <es...@ml1.net> on 2005/05/14 00:54:18 UTC
ScmWagon
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.
This seems like a relatively low impact refactor since the provider
implementations of the commands remain unchanged.
Cheers,
Mike Esler
Re: ScmWagon
Posted by Mike Esler <es...@ml1.net>.
Great. I will take a look at JSR 147, and get started implementing the
basic MKS commands implemented in a new provider.
- Mike
On Sat, 14 May 2005 20:50:42 -0400, "Jason van Zyl" <ja...@maven.org>
said:
> 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
>
Re: ScmWagon
Posted by Jason van Zyl <ja...@maven.org>.
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