"Nick Robinson" <[EMAIL PROTECTED]> wrote: > "Phil Knight" <[EMAIL PROTECTED]> wrote: > > > Chuck Bryan wrote: > > > > > I had a similar question a few weeks ago as I was trying to get > > > Draco and the Nant scripts working correctly. > > > > > > The choices that others had presented where: > > > > > > 1) Put Nant in the same VSS Project Directory (sorry for the VSS > > > terms when you are using subversion). Then, use relative > pathing to > > > address the structure of your source code. > > > > > > 2) Use the VSS tasks that come with Nant. The VSSGet task > allows you > > > to set locations, etc. Draco will still get your files to > its temp > > > directory, but, the build script will then get files and > place them > > > where you want (i.e., a "get" is done twice). > > > > > > I tried both methods, but ended up using option #1 (mostly due to > > > the double get). > > > > I had a similar issue to this, but solved it differently in > the end. I > > modified Draco to pass the temporary folder location as a Nant > > property > > (draco.workdir) to the build script. I could then have a > Nant task move the > > source to the required location. > > > > The modification - to NAntBuildTool.cs - was trivial and > I've attached > > a diff of the changes. I think this might be a useful property for > > Nant to have access to anyway, irrespective of being a way to solve > > the above, so it would be good if this could be > incorporated into the > > Draco code. > > > > Phil > > > > Phil, what is this like in terms of performance? I am > thinking of my current situation, and to move the source > elsewhere after the GET would probably add 1-2 mins. Our > build times are in the 400 seconds as it is. Maybe there > needs to be a rethink about how this aspect of Draco works?
None of our solutions are currently that large so performance isn't really an issue for us at the moment. Since the copy is carried out within local storage then it's fairly quick anyway, but I imagine that if I configured the nant script to do a move (to somewhere on the same volume) instead of a copy then it would be even more efficient (assuming that a move would manipulate directory/file pointers rather than physically copy data). At the very least this must be a better option than the second one given above, i.e. getting a second copy of the source from VSS using nant's vssget task. IMO having draco return the location of the temporary source folder to nant just makes draco that tiny bit more flexible in terms of available options for organising your builds. > I spent the weekend trying to get Draco to use a "working > set" of the source code using VSS (this is just exploration > and isnt expected to be put into production). The idea of > this was that from the Modification list that comes back, if > Draco new all the full pathname and filename to each file > that had been modified, Draco could simply get latest or > delete them as required. But in M$ infinite wisdom, VSS > provides a full path only for Updates. > When a file is removed, or added, you arent told the full > path of the project. If the project hierarchy has the same > name elsewhere in the tree (which is possible), it seems one > wouldnt be able to deduce which project had the add/remove > operation. However, I did prove the concept. Maybe if other > SCC do provide richer information, this could be introduced. Sounds worthy of further investigation. Since build times aren't currently an issue for us (though that's not to say they might not be at some point) I personally prefer draco to kick-off a clean build each time, taking a completely fresh copy of the source. Having said that, just having the ability to specify the location where draco will extract the source could be useful, especially if there could be some kind of "pre fetch" event whereby you could hook in a script to carry out tasks such as labelling the source and cleaning out destination folders etc. Phil ------------------------------------------------------------------------------ DISCLAIMER: This email and files transmitted are confidential and are intended solely for the use of the intended recipient. If you are not the intended recipient, or the person responsible for delivering it to the intended recipient, you may not copy, disclose, distribute or use it in any unauthorised manner. If you have received this email in error please notify us by email to [EMAIL PROTECTED] and then delete it and any attachments accompanying it. Please note that Wolverhampton City Council cannot guarantee that this message or any attachments are virus free or have not been intercepted and amended. Any views or opinions expressed within this email are those of the author and may not necessarily reflect those of Wolverhampton City Council and no contractual arrangement is intended to arise from this communication. ============================================================================== ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Draconet-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/draconet-users
