commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weber, Lance" <Lance.We...@McKesson.com>
Subject RE: [Proposal] Scamp: Source Control Abstraction
Date Tue, 17 Sep 2002 22:16:16 GMT
>>Could it have a less interesting name? 

Well, I had to come up with something quick before someone with a more
cynical nature (ie, me on a Monday)labelled it ;)

"let's see...scam, scum, scram, schism, scream..."


-----Original Message-----
From: Steve Downey [mailto:steve.downey@netfolio.com]
Sent: Tuesday, September 17, 2002 4:07 PM
To: Jakarta Commons Developers List
Subject: Re: [Proposal] Scamp: Source Control Abstraction


I think it's a great idea. There's a lot of commonality between the various 
SCM systems, from the client point of view. There's just one thing.

Could it have a less interesting name? 

When looking through commons, I think we need more names like cli,
discovery, 
collections and logging.

Trying to figure out what betwixt, latka, and jelly do is a challenge. And 
that's a barrier to entry that isn't good in a library code repository.

Just my $0.02.


On Tuesday 17 September 2002 01:53 pm, Weber, Lance wrote:
> Following some interesting discussions on the Maven list, I'd like to
> propose starting an SCM abstraction project, tentatively named Scamp.
>
> Proposed Goal:
> Scamp is a Source Control Manager abstraction layer. It provides a
standard
> interface to SCM systems allowing common source control operations such as
> checkin/checkout, labelling/tagging, reading changelogs and diffs.
>
> Initial design goals:
> -- expose a stable SCM interface contract for consuming applications
> (Maven, Ant, etc).
> -- provide extensible infrastructure for specific SCM implementations.
> -- configuration driven implementations
> -- file system independent
> -- supports multiple projects, multiple/distributed source providers
>
> Architecture:
> My initial thoughts are to utilize a combination of AbstractSCMFactory and
> a SourceControlManager interface with concrete implementations of both. We
> might possible need some secondary classes representing projects,
> connections, and filesystems, but I'm not sure on those yet.
>
> 0.1 Release Goals/Requirements:
> -- First version of SCM Interface, focused on primary/core SCM operations
> -- AbstractSCMFactory
> -- Stubbed concrete factories for cvs/vss/vfs?
> -- exception infrastructure
>
> Any thoughts, feedback, requirements, design, existing code pointers, etc
> very welcome. Potential participants more than welcome!!
>
> Thanks, Lance
>
>
> Lance Weber
> Chief Architect
> CareEnhance Services & Systems
> McKesson Health Solutions
>
>
>
>
>
>
___________________________________________________________________________
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
> for the sole use of the intended recipient(s) and may contain confidential
> and privileged information.  Any unauthorized review, use, disclosure or
> distribution is prohibited.  If you are not the intended recipient, please
> contact the sender by reply e-mail and destroy all copies of the original
> message.


--
To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
 
 
 
___________________________________________________________________________
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
for the sole use of the intended recipient(s) and may contain confidential 
and privileged information.  Any unauthorized review, use, disclosure or 
distribution is prohibited.  If you are not the intended recipient, please 
contact the sender by reply e-mail and destroy all copies of the original 
message.

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message