Thanks everyone for the advice. I tried to say this up front, but I
guess I wasn't clear enough: yes, I know the current workflow is busted,
and I know that both the tool (Robohelp) and the way we're using it is
broken*. We don't control the tool itself; the "foo_generator"
directory I mentioned in my first message is the source processed by the
tool to generate foo (I should have called it foo_src), but the tool
itself is not under our control. Foo is actually "webhelp", by the way.
* The product manager designed and currently maintains the help system.
The HR department is making a concerted effort to let me remove his
commit privileges from svn Real Soon Now. :)
A bug has already been filed in our tracker to fix our process, but we
need to get a new build of our help files into SVN quickly for our next
rev, which means we need a workaround for the existing workflow/toolset.
This is our first help update since our cvs->svn migration, which
explains why we've never run into this problem before.
Ulrich Eckhardt wrote:
> A similar way would be to use the svn_load_dirs script, which would
> have the additional advantage that it automagically adds newly
> generated files and deletes no more generated files.
That might just work, thanks very much. I haven't used svn_load_dirs
yet, so can you please confirm that the process for regenerating the
built help files would be:
1) svn update
2) delete the webhelp dir from the working copy
3) regenerate webhelp from webhelp_generator
4) run svn_load_dirs to commit the new webhelp dir
right?
Thanks,
- Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 18 13:37:00 2005