BK and Generated Files

When using a code management system it is usually the case where it is best to only check in "source" files and use the necessary tools to generate all files that can be generated. One of the reasons for this is because it is very difficult for CM systems to handle file timestamps in a way that "do the right thing" with respect to tools like make in a dynamic code management environment.

For NTP, this becomes increasingly difficult because we are now using GNU AutoGen which requires a number of support tools (including guile), and it is a bit onerous to require all developers to install these tools when very few will be modifying the source files written in AutoGen.

In order to allow us to check in the files generated by AutoGen and have builds proceed normally, we ask developers to run a ./bootstrap script after each 'bk pull' to make sure that updated files are either processed by their respective tools or have their timestamps adjusted so their respective tools are not re-run needlessly.

We are about to start using yacc/bison/byacc in NTP for the new configuration file processing. As different people will have different toolchains, we will either require developers to have some tool to generate these files or we'll have to check in the generated files and update the bootstrap file to handle these new files.

Harlan asked the BK folks if they knew a way that bk could handle this problem. The response was:

Not likely. Can you come up with a rule that applies to all files all the time in push, pull and clone? Like "for all files, every time a file is checked out, use its delta time, and for every time a file is checked in, use the file timestamp time instead of current time".

And deal with the situation that if a file is touched, then built, then a pull happens, the time is moved back, and make doesn't see the need to rebuild? Like having no one modify source file timestamps?

-- BitKeeper Support - 05 Mar 2007

Here's an idea - I suspect y'all can tell me where it falls apart.

During commit, save the mtime of the gfile.

During checkout (clone, etc), get the list of files that are about to be "touched" and the saved mtime from my previous sentence and sort the list in increasing order of that mtime. 'Do' the files in that order (using a 'now' timestamp for each file that gets touched).

-- HarlanStenn - 05 Mar 2007

> During commit, save the mtime of the gfile.

You could do it with triggers.

pre-commit trigger - you keep a file, say 'order', something like:

        bk edit order 
        bk grep -v -f "$BK_PENDING" order > new_order 
        ls -tr `cat $BK_PENDING` >> new_order 
        mv new_order order 
        bk delta -y'added stuff' order 
        exit 0

Then, use a post-incoming trigger and look at the csets that arrived, the files that they changed, and touch them in the order of the order file.

Or something like that. How's that sound?

-- BitKeeper Support - 05 Mar 2007

One thing that concerns me about using triggers for this is that right now I only need triggers for our core machines; doing this would require that all our developers need to use triggers. I suspect it will not be too difficult to separate the two classes of triggers, but I do need to put further thought into this.

-- HarlanStenn - 05 Mar 2007

This topic: Dev > WebHome > BitKeeperNotes > BkAndGeneratedFiles
Topic revision: r1 - 2007-03-06 - 00:57:09 - HarlanStenn
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback