forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Portier" <>
Subject [patch][wip] more partial work done on
Date Fri, 26 Jul 2002 08:50:58 GMT
hoping to finalize this evening, in the mean time there is another quick and
early to look at

mainly because I currently don't have the setup for the deploy.scp testing
(which is copying what nicola and steven have setup for the forrest on
could someone check if that is OK?

- in build.xml
  I started thinking about the generation of logs, not finished yet though
- in forrestbot.conf.xml
  added second project to test the local stuff (seems to work)
  the work in progress...
- config2work.xsl
  is carrying the non change after reverting back the attempt for logs

the new stuff then:
- local get-src and deploy
- deploy scp
- testing on 2 parallel projects (fun to see the <parallel> of ant work so
- check yourself with build clean bot

- for the log: we're now delegating to work.projectname by using <antcall>
  (since it is in the same file)... I'ld like to change that to <ant> so I
  can dump the log via the @output.
  See no reason why it shouldn't work.  A sendlog will just send the log
  to wherever the forrestbot.conf.xml is saying (any ideas on where to put
  there, I was thinking @sendlogto on the <project>
- as stated above: can someone check the scp stuff
- who and why would consider it usefull that one configured <project>
  would have more then one <get-src> and more then one <deploy>
- still thinking about the cvs checkout cache... more comments?
> > have some dream of forrestbot maybe holding a cache of the
> cvsmodules he's
> > regulary updating (delta's rather then full checkouts?) so the
> cache would
> > be kept, and the context dir swept clean on each run of the bot?
> we can keep the cvs check-outs for that purpose, no? when you do an
> update/checkout afterwards, only the changed files are updated

that's the idea, only I should change the dirnames for that

now it is .../cvsmodules/[projectname]/[modulename]
and I think .../cvsmodules/[hostname]/[modulename]/[branchname]
would be better for this purpose?
which reminds me: todo for checking out based on branch

upcoming work (more wip)
- provide deploy.cvs template
- refactor build.xml to use the _templates_
- write a document on TheContract for people to use forrest
  (not like the primer explaining, more a checklist, Bert can maybe
   incorporate in his effort?)
- double-check the todo's just about everywhere around
- check on the 'clean' requirement david posted in another thread.
- more comments in the config2work.xsl needed
- check on cvs checkout based on branch
- check on cvs checkout cache

dream future:
- Ian's discussion on other DTD's might be opened up to 'extending the
  Looking at the build process now: I hope we could snap in new or extend
  workstage-templates easily to gain in flexibility while retaining the ease
of use

View raw message