"Phil Knight" <[EMAIL PROTECTED]> wrote:

> "Nick Robinson" <[EMAIL PROTECTED]> wrote: 
>  
> > "Phil Knight" <[EMAIL PROTECTED]> wrote:
> > 

<<snip>>

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

Thats a fair point.

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

Yes I agree...this would open up Draco to be much more flexible like you say.  

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

I also agree that a clean, fresh build each time is the better option.  In my case, we 
have a 100mbit connection in half of the network and a 10mbit
on the other.  Our source safe server is on the 10mbit along with the draco server.  
Due to office politics, it seems we cannot upgrade these.  The
net result is that getting all of the source code out each time (given that after a 
build, the whole build directory is in excess of 100mb), is that
lots of files go over a very slow netowrk connection.  In this scenario, having a 
working set would be perfect.

I like your pre-fetch event idea.

Nick.
> _______________________________________________
> Draconet-users mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/draconet-users
> 

nick robinson
site   : http://www.fromconcept.co.uk
weblog : http://www.fromconcept.co.uk/weblog.aspx




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

Reply via email to