FYI, I upgraded to the most recent beta version and could not get a forced build by using the client - or after checking in changed files in a monitored project even after double the polling period passed.  It just hung for five or more minutes using the client (at a time until I killed it - for a build that should take < 30 seconds)...  I tried it with and without deleting the files in the root of the program directory that are named after the projects in VSS.

 

I tried it several times -- each was an uninstall/reboot/reinstall -- since the service often failed to start if I didn't reboot in there somewhere.

 

So I stepped backward to the most recent pre-beta build (v1.4.1223.9059) which is newer than what I was using -- it still exhibits the exact same problems of the double build -- but it seems to do all the other things I need right now.  The changes I checked in during the v1.5-beta attempt did get build buy the v1.4 version after I got it installed and started.

 

I'm using Windows XP Professional, .NET Framework 1.1 only, VSS 6.0d (ships with VS.NET 2003), NAnt 0.8.3, and the Draco version noted above; the service is configured to run as a domain account which is an administrator on the machine and a domain administrator (since VSS is on a network share and some of the NAnt copy targets are as well).  If any of that helps.

 

 

 

 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Erv Walter
Sent: Friday, November 07, 2003 5:48 PM
To: [EMAIL PROTECTED]
Subject: RE: [Draconet-users] Why does forcing a remote rebuild wind up triggering two builds?

 

The bug was in the server (not the client), so you’ll likely see the fix when the server is upgraded.

 


From: David Reed [mailto:[EMAIL PROTECTED]
Sent: Friday, November 07, 2003 4:29 PM
To: [EMAIL PROTECTED]
Subject: RE: [Draconet-users] Why does forcing a remote rebuild wind up triggering two builds?

 

I downloaded v1.4.1160.25852 (the most recent pre-beta) of the client and it still exhibits the same problem against the server that's running (v1.4.1223.9059 - which doesn't match anything on the project page for some reason).  When the crew goes home, I'll install another server with the current beta, I guess, and see if it still happens there.

 

 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Erv Walter
Sent: Thursday, November 06, 2003 10:42 AM
To: [EMAIL PROTECTED]; David Reed
Subject: RE: [Draconet-users] Why does forcing a remote rebuild wind up triggering two builds?

 

There was a bug in an older version of draco related to the client tool.  It was screwing up the “last modification date” and showing everything as modified.  This was fixed a while back in CVS and should be fixed in the most recent release (although I am still using an older CVS version, so I haven’t checked the release version personally).

 

The fixed version is still not ideal.  You’ll very likely get a duplicate build after a forced build, but it will only list the changes since the most recent automatic build.

 


From: David Reed [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 06, 2003 9:42 AM
To: [EMAIL PROTECTED]
Subject: [Draconet-users] Why does forcing a remote rebuild wind up triggering two builds?

 

Hola, amigos,

 

Why does forcing a remote rebuild with the Draco.NET Client actually trigger two builds, separated approximately by the poll period in time?  If I (or someone else) force a build with dracocli /start:"Build.Name Project", Draco.NET will fire the build immediately and then one polling period later will rebuild the exact same project, only this time it shows *every* change in VSS history to that VSS project as "Modifications Since Last Build" (which is weird).  The initial "forced" build only shows the most recent changes...  Is there a command line switch or something which would prevent that?  Or is it a remote control bug that is screwing up the cache diff file?  Or something equally odd?  (I'm using draco.exe v1.4.1223.9059.)

 

Remember that I've got 99 monitored VSS projects (and growing), but this only a real problem for VSS projects which contain stored procedures.  The NAnt script keeps a shadow copy of the 500+ sprocs in each project so that only the updated ones are reloaded on the sandbox and integration servers; the NAnt build fails when there are no file changes detected (nothing to reload).  I can change the build script to not failonempty for that fileset so that "no changes" equals a successful rebuild, but...

 

Thanx for you help and insight!

Reply via email to