I think that it will be a very good idea, mostly as a stepping stone to
higher level functionality.

The main reason for not having such a thing is the fact that each
project knows in advance what kind of repository is being in used. So
why do we need something abstract?

On the other hand, once you have such an abstracted functionality, I am
sure we could envision higher level tasks stored on other antlibs that
may provide project management style functionality irrespective of the
underlying repository. That would be a very good thing to have.

So I am all for it. The question is what are the concepts that can be
ported across all different SCMs?

As per syntax, I would much prefer something like:

 <scm:commit ...../>

Now, can this be done in such a way as to figure out by itself what is
the underlying repository is. That would limit the need for magic stuff.

Jose Alberto

> -----Original Message-----
> From: Kev Jackson [mailto:[EMAIL PROTECTED]
> Sent: 27 September 2005 07:34
> To: Ant Developers List
> Subject: suggestion refactor SCM
> 
> Hi
> 
> I've been playing with darcs recently and I've almost finished an
antlib
> for it (though I keep being distracted, first Haskell, now Lisp....).
> 
> 'darcs get' is roughly similar to 'cvs checkout' or 'svn co'
> 
> I was wondering if it would make sense to refactor the SCM tasks into
an
> interface (scm) and have a set of antlibs that implement that
interface
> in a vendor specific manner.  Such that
> 
> <scm command="commit">
> 
> is handled appropriately by each SCM system in it's own way, whilst at
> the same time exposing a common API to simplify this (very common) set
> of tasks.  I'm thinking it'd be similar to how the <javac> task
> simplifies compiling regardless of which compiler you want to use.
> 
> Is this:
> a - a stupid idea and a colossal waste of time
> b - a not too stupid idea, but still a colossal waste of time
> c - not stupid, a colossal waste of time, but it'd be worth doing
anyway
> d - none of the above
> 
> Kev
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to