Building target disrupts source control

[Ron T]

I've put a project into TortoiseSVN. This works OK until I rebuild my webhelp target and Flare overwrites all the output files and directories, including all the hidden .svn files that SVN uses for tracking. Why does this happen? Will binding to source control through Flare using PushOK's plugin for SVN fix this?
Thanks,
Ron

[i-tietz]

Flare deletes the (target) relevant output folder and starts from scratch with every build.

But why do you have the output folder in the versioning database at all? You should keep the sources in the database so you can retrieve them from there and build an output from those sources at any time.

[Ron T]

A sw developer checks out the WebHelp output using SVN to integrate into his GUI app, so I can't exclude the Output folder fron source control. Is this an inappropriate use of source control? What's the best way to handle this?

[Andrew]

A sw developer checks out the WebHelp output using SVN to integrate into his GUI app, so I can't exclude the Output folder fron source control. Is this an inappropriate use of source control? What's the best way to handle this?

I would think you'd have to publish the output to an SVN-controlled folder (rather than merely building).

[RamonS]

Unless versioning is needed I'd keep the sources in SVN and provide an output on a network share for the install process to use. As Inge (i-tietz) pointed out, source control is for controlling sources (d'oh), which means anything compiled should not be in there. It does not server any purpose and really only bloats the system. If it wasn't for the .svn files I'd recommend leaving it the way it is rather than to cause a lot of work to overcome a technicality, but in your case the deletion of the .svn file is the core problem and the easiest solution would be not to have the output in SVN.

[Ron T]

Well, what you say makes plenty of sense. However, the software developer wants a way to run a compile process and have a guarantee that his compiled output used the latest version of the Flare WebHelp output. We could, of course, check out the Flare sources and build output at compile time but that would require purchasing another copy of Flare, which we certainly can't afford. Do you know of another way to solve this problem?

[RamonS]

Yes, you provide a build of the help when it makes sense, even if that means that the same output is compiled in for a few days or even weeks. Half-written topics and empty shells in the help are rather useless. If the developer barks at that, tell him/her that it is like checking in a code module only once it is done. A half completed module is of no use to anyone and makes no sense to be included in a build (as it shouldn't be used by anything at that point). Besides that, the sources are in source control. I doubt the devs check in the compiled app or even the installer files into SVN (although, I've seen this happen).
It should be possible to amend the build process to grab the files from a network share.

[i-tietz]

That's what we do. We publish our help to a specific folder on our network and the developers haev automated scripts that copy it from there. Right now we're doing that with .chm files (produced with Flare) and tons of PDFs (created with FrameMaker).
We can even work on different versions of the help, just like development does - patches for the current version and trials of the next version.

[Andrew]

That's what we do. We publish our help to a specific folder on our network and the developers haev automated scripts that copy it from there. Right now we're doing that with .chm files (produced with Flare) and tons of PDFs (created with FrameMaker).
We can even work on different versions of the help, just like development does - patches for the current version and trials of the next version.

We do that with one of our flagship products (an older, Windows client-based app), and with the newer products (the ones that are all "web-based") we have to check the help output into Perforce so that release engineering can use their P4 scripts to grab it and package it all up. I'm not really a fan of that process, but I'm not making the decisions.