Logfiles hardly accessible after changing repos path

[thomas.moschny@…]

After changing the repository path a certain build configuration listens on, the logs of earlier builds vanish from that configuration's history page. (They remain accessible via their build number.) The reason seems to be that the builds are found by walking revisions backwards from the currently configured repos path.

Imho this confuses concepts though. After a build has been finished (or aborted fwiw) based on a certain configuration, its logs should forever (unless purged somehow) be tied to that configuration, regardless of what the current settings within that configuration are.

And this also has nothing to with the fact whether old and new path have a is-a-copy-of relation, or not - opposed to the idea the comment in source:trunk/bitten/queue.py@515#L60​ might be based on.

[dfraser]

#329 (storing logs in files) may be related

[osimons]

Confirmed (when testing #158). I've tried all kinds of tweaks to get builds listed again, but even reverting path and limiting revisions to known revisions of original path does not seem to be enough.

I think I agree with you: A build for a config should stay with the config even if repos path changes.

I'll put it on my todo.

[osimons]

#244 is somewhat related to this.

[osimons]

Patch that implements full working build history across repository copy/move.

[osimons]

I've made a patch for this. It traverses history across copy/move provided there are existing builds for config at that earlier path. It even supports invalidating and rebuilding such builds as usual, and will traverse the path history to discover the original value for ${path} at the particular revision, and send this to the slave as part of config - allowing the slave to for instance checkout repository at correct location.

As Bitten currently works, there cannot be support for changing repository path without sharing a forward history from original location as there would be no way of discovering the value for ${path}.

Perhaps what remains for this patch is to make that restriction explicit, so that arbitrary changes of path are not possible if any builds already exists for the configuration. Throw an error in webadmin if path is changed to something that don't have the current path in immediate history.

Either that, or just leave it as it now stands and let those builds just stay visually orphaned. Comments?

[cboos]

For following the copy history, get_path_history is not appropriate as it shows only the add/edit/remove on a given path. The regular get_history is more fitting. See also ​#T8301, which shares a similar concern with scoped repository. The suggested SubversionNode.get_copy_ancestry might be useful here as well.

[osimons]

Thanks for input, cboos. As it now stands, I think the best solution is storing the config path on each build at build creation, so that each build remember both its revision and path. That way there won't be a need to traverse history to try to figure this out - and even handle moving config to locations without an immediate shared history.

That requires a db change, and I'll likely see that in context with some other requests for config/path changes for 0.7.