ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From JP Fiset>
Subject Re: suggestion refactor SCM
Date Tue, 27 Sep 2005 12:40:39 GMT
It certainly is an interesting idea. I think the main challenge in this 
endeavour is to figure out what is the common denominator between all 
the SCM systems and then assess if it is encompassing enough to warrant 
abstracting it out.

I wish this effort will not be limited to tasks, but will also include 
file sets and file selectors, since I feel it is necessary in managing a 
source repository properly. For example, in svn-ant (the subversion ant 
lib), I implemented file selectors to discriminate files based on status 
such as: added, replaced, unversioned, ignored, etc. That, in itself, 
was not enough. I needed to also provide a file set, since subversion 
has a concept of "missing" and "deleted" files. Obviously, a classic 
file set can not predict files that are not present on the file system, 
so a custom file set had to be designed.

While tasks might have to be limited to common functionality (why 
develop a script based on a task that keeps failing on a majority of SCM 
systems), file selectors can combine the richness of all SCM systems. If 
a SCM system does not support a concept, then the related file selector 
would never tag any file. Scripts based on those file selectors would be 
valid, regardless of the underlying SCM system.


Kev Jackson wrote:
> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message