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.
JP
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
