Committing Output files to SVN

[truesdk]

We have a build system which requires one of two things:

1. Output files must be committed to SVN (so that the build process can check out the built output files and push the files to 1 or many servers)

2. (as an alternative to 1) Project files must me able to be checked out of svn on to a Unix machine and unix must be able to generate the output files.
(This one requires a MadCap Library for Unix systems which i can not seem to find...)

The main question is: Is there a way to have MadCap automatically commit output files when checking in changes to a project?
(Removing the dependency of installing another svn client on the machine and doing a dual commit)

[RamonS]

I suggest a third option of publishing the output files to a file server from where the build process can pick them up. There is generally no need to keep compiled output in source control, be it binaries or help output.

[Colum]

We have a similar requirement where we have two sets of WebHelp files. One set is published to an internal server, but the other is picked up by the build from SVN. I see that if we use the SVN integration provided by Flare we can't commit the output files. However we can if we do a manual commit.

So if we use the SVN integration to check in all the files EXCEPT the webhelp output files, is there anything to stop us subsequently to manually commit the output files to the appropriate SVN repository as a separate step?

[RamonS]

No, you can commit any file you want to SVN. The question is if it makes sense to submit compiled output to a source control system and needlessly bloat SVN. For the same reason compiled code (executables and libraries) do not get checked into source control, help is no different.

[Colum]

Thanks for responding Ramon but I am still unclear. The help explicitly states, "With the built-in integration, you cannot transfer the output files." Is this just saying that the integration does not recognise the output files as being part of the project and therefore ignores them? If so I can manually add them to SVN.

I agree with your sentiment about bloating SVN but this is a tried and tested procedure that works seamlessly for both the documentation and development teams. It is as near to full automation as we are ever likely to get. Besides storage is cheap these days

[RamonS]

Yes, Flare will not submit the output, but you can do so manually.
And yes, storage space is cheap, but waiting for a bloated system to respond is not. For that reason Madcap has build licenses so that the command line build can be integrated in automated processes. There really is no need to store compiled output of any kind in source control.

[Nita Beck]

Actually for one of my clients, we do put output in SVN. We manually zip up the output files, and we name the zip file in a specific way to identify its contents. We manually copy them to an "OutputArchive" folder in SVN. Although we also create tags in SVN whenever we deliver a release of output, we decided to put the output itself in SVN so that we could eliminate the need of having to recreate it. Yes, we could just import a copy of an SVN tag into Flare, but maybe the output was originally created with, say Flare 7, and now features have changed in Flare 9. Rather than having possibly to fiddle around with differences between versions of Flare in order to regenerate that old output exactly as it was originally generated, we'd rather just manually go out to SVN and fetch that old output. Given that there are multiple Flare authors in different departments and on different network drives, it just made sense to us to put ALL of our Flare-related stuff -- source AND output -- into SVN. Everyone knows then how to find anyone else's stuff, if ever the need arises.

We're not using the command-line build processes, so perhaps my story might be moot. But I wanted to make a case for why output might sometimes be put into SVN.