Re: suggestion refactor SCM
Trygve Laugstøl a écrit : On Wed, 2005-09-28 at 16:56 +0100, Jose Alberto Fernandez wrote: From: Steve Loughran [mailto:[EMAIL PROTECTED] Jose Alberto Fernandez wrote: But here we seem to be talking about a new family of generic tasks, If this works well, we could deprecate the old tasks and eventually in a couple of versions remove them. Jose Alberto generic is good, provided -we can have a conceptual model that is consistent across all SCM systems. -we can deal with extensibility through antlibs. I suppose you'd have a new type, SCMbackend that every backend would implement; declaring a new backend would let you register it. Question: could you just get away with some mixin import lib that declared the appropriate macros for the appropriate platform? Well, it seems that the maven people have such a thing to some extend already. This new antlib tasks could use that support. Hey, maybe maven-scm could host and provide the antlib for these tasks. Or maybe they are willing to move it to our sandbox. I still think, it will be a good idea if we continue to get involved to help define the overall picture from the ANT perspective. With my Maven SCM Committer hat on I would not object to hosting the Ant tasks under Maven SCM if that's what you guys feel is right. Your call but I'm +1 to having them under Maven SCM. I'm +1 too At the end of the day we would have to decide if we would like to provide these libraries as part of our release, provide some 3rd party goodies that you can download as part of ANT, or just tell people about their existence somewhere. -- Trygve Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: suggestion refactor SCM
Kev Jackson wrote: On 29 Sep 2005, at 06:39, Brett Porter wrote: I'd also agree with that. We fully intended to make Maven2 plugins work as Ant tasks :) So with a wrapper, http://maven.apache.org/maven2/scm/maven-scm-plugin/ these goals would become tasks and their parameters would match up what's on the individual pages. Thoughts? Just a worry about dependencies. If Ant has to rely on other code from within maven for a set of maven plugins to run, we end up with a horrible interdependency (Maven needs Ant - Ant needs some % of Maven) just to compile ant. Could get nasty. But I agree if the work is there and the code can be taken and made common between projects, why not? Not needed to build, only to run the SCM stuff. I'm already working with stuff from many places, which is the main reason my gump projects are so unreliable (that and the XmlBeans willingness to remove attributes from shipping tasks, but the forthcoming hasMethod condition will deal with that) ... project name=sftasks xmlns:ac=antlib:net.sf.antcontrib xmlns:sf=antlib:org.smartfrog.tools.ant xmlns:m2=antlib:org.apache.maven.artifact.ant One thing we do have to have is ant task tests in maven, which means that the ant team has to put the ant-testutils.jar up on the repository, and work out how to run those tests under m2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: suggestion refactor SCM
From: Kev Jackson [mailto:[EMAIL PROTECTED] On 29 Sep 2005, at 06:39, Brett Porter wrote: I'd also agree with that. We fully intended to make Maven2 plugins work as Ant tasks :) So with a wrapper, http://maven.apache.org/maven2/scm/maven-scm-plugin/ these goals would become tasks and their parameters would match up what's on the individual pages. Thoughts? Just a worry about dependencies. If Ant has to rely on other code from within maven for a set of maven plugins to run, we end up with a horrible interdependency (Maven needs Ant - Ant needs some % of Maven) just to compile ant. Could get nasty. But I agree if the work is there and the code can be taken and made common between projects, why not? But this is the beauty about antlibs. There is no reason why these tasks should generate any dependencies on ANT. They are a library that is either present (the tasks available) or not present (the tasks not available) as long as building the ant-core (the bootstrapping) does not require using this tasks there should be no issue. Am I missing something? Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: suggestion refactor SCM
On 9/27/05, Emmanuel Venisse [EMAIL PROTECTED] wrote: Jose Alberto Fernandez a écrit : 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? In Maven-SCM, we have some abstract beans for each commands (checkout, checkin, update, changelog...) in an abstract api, Each provider implement these beans for obtain an accessible command in framework for this provider. We support actually clearcase, cvs, local, perforce, starteam and in few weeks, Serena Dimension (PVCS). For your information, I am about to propose CruiseControl to reuse this library. We currently support 14 SCM, but most of the time only the changelog functionality is supported. Cheers, Jerome - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: suggestion refactor SCM
Great news. So you'll can provide new providers. Emmanuel jerome lacoste a écrit : On 9/27/05, Emmanuel Venisse [EMAIL PROTECTED] wrote: Jose Alberto Fernandez a écrit : 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? In Maven-SCM, we have some abstract beans for each commands (checkout, checkin, update, changelog...) in an abstract api, Each provider implement these beans for obtain an accessible command in framework for this provider. We support actually clearcase, cvs, local, perforce, starteam and in few weeks, Serena Dimension (PVCS). For your information, I am about to propose CruiseControl to reuse this library. We currently support 14 SCM, but most of the time only the changelog functionality is supported. Cheers, Jerome - 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]
RE: suggestion refactor SCM
But here we seem to be talking about a new family of generic tasks, If this works well, we could deprecate the old tasks and eventually in a couple of versions remove them. Jose Alberto -Original Message- From: Martijn Kruithof [mailto:[EMAIL PROTECTED] Sent: 27 September 2005 16:57 To: Ant Developers List Subject: Re: suggestion refactor SCM Hi, The standard problem with any kind of refactoring is the backward compatibility requirement on source code level. There are a lot of constructs we'd like to remove, but upto now we have always weighted backward compatibility - even on source code level - over removing those. Martijn 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: suggestion refactor SCM
Jose Alberto Fernandez wrote: But here we seem to be talking about a new family of generic tasks, If this works well, we could deprecate the old tasks and eventually in a couple of versions remove them. Jose Alberto generic is good, provided -we can have a conceptual model that is consistent across all SCM systems. -we can deal with extensibility through antlibs. I suppose you'd have a new type, SCMbackend that every backend would implement; declaring a new backend would let you register it. Question: could you just get away with some mixin import lib that declared the appropriate macros for the appropriate platform? -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: suggestion refactor SCM
From: Steve Loughran [mailto:[EMAIL PROTECTED] Jose Alberto Fernandez wrote: But here we seem to be talking about a new family of generic tasks, If this works well, we could deprecate the old tasks and eventually in a couple of versions remove them. Jose Alberto generic is good, provided -we can have a conceptual model that is consistent across all SCM systems. -we can deal with extensibility through antlibs. I suppose you'd have a new type, SCMbackend that every backend would implement; declaring a new backend would let you register it. Question: could you just get away with some mixin import lib that declared the appropriate macros for the appropriate platform? Well, it seems that the maven people have such a thing to some extend already. This new antlib tasks could use that support. Hey, maybe maven-scm could host and provide the antlib for these tasks. Or maybe they are willing to move it to our sandbox. I still think, it will be a good idea if we continue to get involved to help define the overall picture from the ANT perspective. At the end of the day we would have to decide if we would like to provide these libraries as part of our release, provide some 3rd party goodies that you can download as part of ANT, or just tell people about their existence somewhere. Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: suggestion refactor SCM
On Wed, 2005-09-28 at 16:56 +0100, Jose Alberto Fernandez wrote: From: Steve Loughran [mailto:[EMAIL PROTECTED] Jose Alberto Fernandez wrote: But here we seem to be talking about a new family of generic tasks, If this works well, we could deprecate the old tasks and eventually in a couple of versions remove them. Jose Alberto generic is good, provided -we can have a conceptual model that is consistent across all SCM systems. -we can deal with extensibility through antlibs. I suppose you'd have a new type, SCMbackend that every backend would implement; declaring a new backend would let you register it. Question: could you just get away with some mixin import lib that declared the appropriate macros for the appropriate platform? Well, it seems that the maven people have such a thing to some extend already. This new antlib tasks could use that support. Hey, maybe maven-scm could host and provide the antlib for these tasks. Or maybe they are willing to move it to our sandbox. I still think, it will be a good idea if we continue to get involved to help define the overall picture from the ANT perspective. With my Maven SCM Committer hat on I would not object to hosting the Ant tasks under Maven SCM if that's what you guys feel is right. Your call but I'm +1 to having them under Maven SCM. At the end of the day we would have to decide if we would like to provide these libraries as part of our release, provide some 3rd party goodies that you can download as part of ANT, or just tell people about their existence somewhere. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: suggestion refactor SCM
I'd also agree with that. We fully intended to make Maven2 plugins work as Ant tasks :) So with a wrapper, http://maven.apache.org/maven2/scm/maven-scm-plugin/ these goals would become tasks and their parameters would match up what's on the individual pages. Thoughts? - Brett On 9/29/05, Trygve Laugstøl [EMAIL PROTECTED] wrote: On Wed, 2005-09-28 at 16:56 +0100, Jose Alberto Fernandez wrote: From: Steve Loughran [mailto:[EMAIL PROTECTED] Jose Alberto Fernandez wrote: But here we seem to be talking about a new family of generic tasks, If this works well, we could deprecate the old tasks and eventually in a couple of versions remove them. Jose Alberto generic is good, provided -we can have a conceptual model that is consistent across all SCM systems. -we can deal with extensibility through antlibs. I suppose you'd have a new type, SCMbackend that every backend would implement; declaring a new backend would let you register it. Question: could you just get away with some mixin import lib that declared the appropriate macros for the appropriate platform? Well, it seems that the maven people have such a thing to some extend already. This new antlib tasks could use that support. Hey, maybe maven-scm could host and provide the antlib for these tasks. Or maybe they are willing to move it to our sandbox. I still think, it will be a good idea if we continue to get involved to help define the overall picture from the ANT perspective. With my Maven SCM Committer hat on I would not object to hosting the Ant tasks under Maven SCM if that's what you guys feel is right. Your call but I'm +1 to having them under Maven SCM. At the end of the day we would have to decide if we would like to provide these libraries as part of our release, provide some 3rd party goodies that you can download as part of ANT, or just tell people about their existence somewhere. -- Trygve - 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]
Re: suggestion refactor SCM
On 29 Sep 2005, at 06:39, Brett Porter wrote: I'd also agree with that. We fully intended to make Maven2 plugins work as Ant tasks :) So with a wrapper, http://maven.apache.org/maven2/scm/maven-scm-plugin/ these goals would become tasks and their parameters would match up what's on the individual pages. Thoughts? Just a worry about dependencies. If Ant has to rely on other code from within maven for a set of maven plugins to run, we end up with a horrible interdependency (Maven needs Ant - Ant needs some % of Maven) just to compile ant. Could get nasty. But I agree if the work is there and the code can be taken and made common between projects, why not? (When you first replied Brett, I checked out the source in svn web thingy and I saw a fair bit of codehaus imports - I personally don't have any good experience (as a user) of anything from codehaus so I'm wary of that code, but you obviously have a more in depth view) - Brett On 9/29/05, Trygve Laugstøl [EMAIL PROTECTED] wrote: On Wed, 2005-09-28 at 16:56 +0100, Jose Alberto Fernandez wrote: From: Steve Loughran [mailto:[EMAIL PROTECTED] Jose Alberto Fernandez wrote: But here we seem to be talking about a new family of generic tasks, If this works well, we could deprecate the old tasks and eventually in a couple of versions remove them. My thoughts were that in the future you'd download a base-ant, and then depending on the SCM you use you'd download the scm-provider- ant.jar eg base-ant1.8.jar + svn-ant.jar Each antlib is going to be tiny compared to the amount you have to download for all SCM functionality that we currently have (I'm still on dial-up here so download speed and size of code is important to me :) ) generic is good, provided -we can have a conceptual model that is consistent across all SCM systems. -we can deal with extensibility through antlibs. I suppose you'd have The hard part is defining a consistent interface which is applicable to all SCM systems, without dropping down to lowest common denominator. Kev -- In vain you tell me that Artificial Government is good, but that I fall out with the Abuse. The Thing! The Thing itself is the Abuse! - Edmund Burke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: suggestion refactor SCM
On 9/29/05, Kev Jackson [EMAIL PROTECTED] wrote: Just a worry about dependencies. If Ant has to rely on other code from within maven for a set of maven plugins to run, we end up with a horrible interdependency (Maven needs Ant - Ant needs some % of Maven) just to compile ant. Could get nasty. But I agree if the work is there and the code can be taken and made common between projects, why not? Mavne, in general, doesn't need ant. Of course, ant tasks in this code would require ant, but if they are here I assumed they would be an antlib, not a part of the ant build. (When you first replied Brett, I checked out the source in svn web thingy and I saw a fair bit of codehaus imports - I personally don't have any good experience (as a user) of anything from codehaus so I'm wary of that code, but you obviously have a more in depth view) The main part should only require plexus-utils, which we are trying to migrate to unify under commons-exec and commons-io. My thoughts were that in the future you'd download a base-ant, and then depending on the SCM you use you'd download the scm-provider- ant.jar eg base-ant1.8.jar + svn-ant.jar Each antlib is going to be tiny compared to the amount you have to download for all SCM functionality that we currently have (I'm still on dial-up here so download speed and size of code is important to me :) ) All the providers together aren't that large, though you do need the option to add other providers later. The hard part is defining a consistent interface which is applicable to all SCM systems, without dropping down to lowest common denominator. Yep, we've held some discussions around this and there is still some work to do to get to a good common api. Other things particular to an SCM should then be exposed by extensions. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
RE: suggestion refactor SCM
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]
Re: suggestion refactor SCM
Jose Alberto Fernandez a écrit : 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? In Maven-SCM, we have some abstract beans for each commands (checkout, checkin, update, changelog...) in an abstract api, Each provider implement these beans for obtain an accessible command in framework for this provider. We support actually clearcase, cvs, local, perforce, starteam and in few weeks, Serena Dimension (PVCS). I think it will be great if we can contribute together to it. Maven-SCM is totally independant of an other framework, so it can simply be used in ant, maven, continuum, standalone app... We actually use it in maven1, maven2 and continuum Emmanuel 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: suggestion refactor SCM
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]
Re: suggestion refactor SCM
Hi, The standard problem with any kind of refactoring is the backward compatibility requirement on source code level. There are a lot of constructs we'd like to remove, but upto now we have always weighted backward compatibility - even on source code level - over removing those. Martijn 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]
Re: suggestion refactor SCM
Hi, The standard problem with any kind of refactoring is the backward compatibility requirement on source code level. There are a lot of constructs we'd like to remove, but upto now we have always weighted backward compatibility - even on source code level - over removing those. Martijn 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]
