Clayton Harbour wrote:

I like the nested command and it looks like it would be

easy to extend

something like this into some sort of pluggable version

control 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.


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.

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 to
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).


Hmm - 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.

This is to make it
easy to understand one syntax in NAnt and apply it to the different
version control systems that you might use in your career.




see my point above.


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 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.

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

Reply via email to