[Buildbot-devel] bonsai "one rev per file" patch

[Brian Warner]

>> Any ideas? I'm tempted to remove the revision-number comment, but you know
>> better than I do what the bonsai/tinderbox stuff needs.
>
> Hm. Maybe we could have one Change per file instead of per bonsai's idea 
> of "changeset" (which is only really useful for humans AFAICT).

The Buildbot could basically handle that (since all the Changes would be
delivered at about the same time, so they'd all get lumped into the same
build). It could get kind of messy on the Waterfall page, though, since you
could have dozens of Changes showing up for each build.

Worse than that, though, you really couldn't put individual revision numbers
on each Change.. the change.revision attribute needs to be a tree-wide value,
and the only thing that serves that purpose in the CVS world is a timestamp.
The CVS checkout step, for example, takes the max() of all the .revision
values from all its Changes to determine what to use for the checkout/update
command. Using, e.g., "1.45" for .revision is going to break it horribly.
This is a place where SVN/P4/Arch's repository-wide transaction number is a
lot easier to deal with.

These revision numbers are really only intended for human consumption
anyways, right? What if you just appended some text to the change comments to
record the versions?:

 comments = cinode.log + "\n\n"
 for file in cinode.files:
     files.append(file.filename)
     comments += "%s (revision %s)\n" % (file.filename, file.revision)

Or are they intended for machine parsing at the other end (in the text
emitted by the TinderboxMailNotifier)?

cheers,
 -Brian