> 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.
CVS is simple. Ultra simple. Various VCSes have different concepts and
features so I don't think that implementing a pluggable task will give us
anything. I don't believe that switching from <cvs> to <svn> would be really
a matter of changing 3 characters in the buildfile. There is new approach to
version numbers which must be taken care of. Personally I think that the
decision to switch VCS is not something you make every day and there's no
reason to support such usage.
Each task should be easy to use, instead of being general and pluggable.
If you want code reuse, you can create a parent class which is not a task
and inherit actual tasks from it (cvs-update, cvs-checkout, cvs-tag, ...).
This is similar to what all .NET compilers do.
> The wrapper task would have to be generalized a bit (i.e. include a
> server, port, protocol, etc. instead of a munged root value) maybe
> something like:
> <cvs server="foo.com"
> remotepath="/blah/blah"
> module="foo"
> user="me"
> password="come-on-in"
> passfile="/blah/blah/.cvspass"
> localpath="c:/blah/blah"
> ssh="c:/bin">
> <update clean="true">
> <fileset>
> <inclues name="AssemblyInfo.cs"/>
> </fileset>
> </update>
> <update />
> <tag />
> <export todir="outputdir" />
> </cvs>
Tell me, how often do you do things like that? I cannot think of anything
more advanced than:
<checkout>
... modify something (like AssemblyInfo.cs) ...
<tag />
... build ...
<commit>
> Jarek's I think that this idea also combines use of common names instead
> of option switches. I am not sure that I understand the reference to
> modulo attribute names, could you please explain how the above is
> different?
I just want a simple syntax
<cvs-update ... attribute1="value" attribute2="value" ...>
<fileset>
</fileset>
</cvs-update>
"modulo attribute names" means I haven't taken time to check the docs for
the exact attribute names. That's all.
> Also I have included an example of what nested commands
> might be used for. I have seen something like this in build files
> however I am not sure I like it and prefer to add a build between the
> update and tag.
It's not very usable. Really. There's no reason to invent a complicated
two-level structure just because some tasks have some common attributes.
> Finally this accomplishes another thing, which is
> keeping the interface/ task tags that are needed to a minimum which.
Why do you want this?
> Switching to something like <vcs type="cvs" /> might be even
> better...but maybe I am getting ahead of myself.
-1 to this idea.
> So...where do we go from here?
Gert, Ian, Scott? What do you think?
Jarek
-------------------------------------------------------
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
