Steve Loughran wrote:
Kev Jackson wrote:
Kevin Jackson wrote:
Standard Ant contains a number of VSS tasks and I'm writing a couple
more for my own use (tasks relating to file / project properties, such
as shared versions). My questions are: should I submit these tasks for
possible inclusion in the standard Ant distribution? And if so, do you
have any advice on the best way to do that? I've read the "Task
Design
Guidelines", by the way.
Anybody have a problem with splitting VSS off into an antlib so that
people with VSS can easily add tasks etc? I recall that there are
also a couple of bugs listed (enhancements and patches) for VSS, but
without anyone willing to test them, they aren't going to be worked
on. I see an antlib being useful here, but would like to know what
other people think.
I've knocked together an antlib for vss against 1.7 trunk.
I still need to write the testcases (JUnit + xml files), but is there
any interest in this approach so that the VSS users can add commands
/ support VSS outside of the dev cycle for Ant proper?
We do have quite a few outstanding issues for VSS and very few (if
any) of the committer team have access on a regular basis to a VSS
install
I used to, but then discovered how drastically it can get corrupted,
and stopped. I dont even have a vs.net or vss client installed on a
laptop or vmware image right now.
Having spent the past hour or so getting VSS to acknowledge Ant
interacting with it (or indeed even the MS supplied command line
tools), I'm in favour of pushing all of this code off into an ant lib
which the users can manage by themselves!
+1
Unfortunately this would count as a code change and would have to go
through a formal vote, I'd still like some more feedback before
proposing a vote which may be a waste of time.
FYI, I'd be willing to put in the initial effort to deliver an antlib
if the rest of you thought it was worthwhile - indeed it's mostly
there already, and I'd be willing to incorporate additional code into
this antlib - *for the next two weeks while I have access to VSS*
Tests are interesting. What could be done is a precreated vss database
that could be used as a starting place, but to run the tests you'd
still need a VSS client, which is actually hideously overpriced (can
you say hundreds of dollars?). Maybe the new freebie vs.net express
tools bundle a free vss client though...
It's actually one of those things where an open source reverse
engineered client would actually be useful, as you mention, the price
that you must pay to use VSS is outrageous. The problem I guess is that
anyone with the skills to reverese engineer the VSS client, certainly
doesn't have the inclination to bother!
Now, if we have tests for VSS then maybe I could build up a vmware
image which could be used to intermittently host test runs. I was
thinking of building up windows 2003 and windows vista images, though
for the latter I'm holding off till a slightly better build comes out
than last month's; it takes so long to install Vista I'm not that
motivated to waste the time just yet.
Yes thats another problem, the tests are bound to a configuration of VSS
+DB that will not be available to gump, so I could build a whole set of
tests for all the functionality we currently provide, then they would be
next to useless for someone else without first configuring a vss db in
the exact same manner. At least with svn we actually have an svn repo
to test against :)
Kev
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
