Perhaps this would help;
In BuildRunner.cs, selecting the temp build directory and retrieving the
source code is the reponsibility of GetSource() as below.
private string GetSource() {
string temp = Path.GetTempFileName();
File.Delete(temp);
Directory.CreateDirectory(temp);
IRepository scc =
RepositoryFactory.CreateRepository(processRunner, build);
scc.Login();
scc.GetSource(temp);
return temp;
}
If the DracoBuild object was modified slightly, these features could
then become configurable via the <build> in the draco.net.config file.
For example;
private string GetSource() {
string temp = build.GetBuildDirectory();
if (!build.DoNotGet()) {
IRepository scc =
RepositoryFactory.CreateRepository(processRunner, build);
scc.Login();
scc.GetSource(temp);
}
return temp;
}
Assume everything works by default the same as it does today. But
suppose you want draco to compile against the sourcesafe shadow
directory on the network. Changing Draco to support a build config file
that looks like this:
<build builddir="\\svr\share\shadow" donotget="true" >
<name>project</name>
should accomplish what is needed, and would be rather simple to develop,
since it is mostly a matter of moving a few lines of code around. This
also would be nice for Nant based builds that are designed to get the
source too.
- Jerry
> 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
-------------------------------------------------------
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_id78&alloc_id371&op=click
_______________________________________________
Draconet-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/draconet-users
