I think you'll find that there are enough serious differences between most version control systems that making a framework abstract enough to cater to enough of them will result in a least common denomonator solution. This is what microsoft attempted with their SCC interfaces in Visual Studio and in my experience they have been a dismal failure. The main reason being that it forces you into looking at version control in a certain way - which may not map well to your particular system.I like the nested command and it looks like it would beeasy to extend
something like this into some sort of pluggable versioncontrol task.
Why do you want to do it? The last thing we need here is abstraction.
I would like to do this because it provides a framework to add more
version control systems. A framework will make it easier to add and use
different version control systems.
A revision control system is somthing that you work with every day and generally know quite well. In my view people would prefer nant tasks for a given system to map well to that system rather than to a generalised version control framework that we come up with.
This is not to make it easy toHmm - I don't see 'svn will be a drop in replacement for cvs' on that page and I don't believe it will be. They have kept the command line interface fairly similar to minimise migration pain but not with the aim of being able to switch back and forth between the two.
switch your project from <cvs/> to <vss/> (although I believe this
switch will be possible from cvs to subversion, as this is one of
subversion's design goals:
http://subversion.tigris.org/project_faq.html#why).
This is to make itsee my point above.
easy to understand one syntax in NAnt and apply it to the different
version control systems that you might use in your career.
I disagree. When a project changes Version Control systems their will be substantial pain whether or not some NAnt tasks attempt to smooth over the differences with a common framework. In fact this will probably add more pain as you'll then need to work out how the NAnt framework maps the version control System X. Version control systems are sufficently different that an all encompassing framework is quite probably going to be more trouble than its worth.
keeping the interface/ task tags that are needed to a minimum which.
Why do you want this?
Again so it is easier to use with different systems, when a different version control is mandated, when you decide to upgrade to svn the syntax is the same, when you change projects, the command is similar and it is an eas(ier) transition. When someone decides that version control system X is better than version control Y and wants to add this to NAnt you can extend the current framework and keep some consistency for the end user.
I think if you try to implement say bitkeeper or clearcase tasks using the current structure you'll see what I mean.
Ian
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Nant-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-users