Skip to content

resolves Issue 188: symlinks

David Jencks requested to merge djencks/antora:issue-188-symlinks into master

This is now ready for initial review. packages/content-aggregator/devdocs/symlinks.adoc attempts to explain what it does and how; it also includes a lot of historical cruft.

  • In the nature of things, a lot more information about problems is available through git than through the worktree file system access. At this point I suggest we output the information available from each source. It would be possible perhaps to replace the file system scanning and get the equivalent info, but if that's desirable lets do it later.

  • At the moment, the git access 'logs' to console.error detailed information about the problem and just continues. This is my preferred behavior... I like to get as far as possible to find out about as many errors as possible at once. I'd be completely open to failing at the end of content-aggregation if there are any of these symlink errors. I'd argue strongly against stopping after the first one. (The worktree support stops after the first symlink error, and I haven't discovered a way to avoid that).

  • In order to understand what was going on I had to add a bunch of (console) logging, which I've left in place behind a DEBUG && expression. Since we plan to add logging soon (!) I'd suggest leaving this here for easy conversion to trace level logging.

  • There are some test scenarios for unsupported cases, without a test. I checked "by hand" that these don't cause serious problems, but I'm not sure if or how there could be automated tests for them.

  • I don't understand quite why the 'skip' test doesn't work and why it thinks it needs to know a remote, but it's a pretty odd scenario. The previous test, building against the Antora worktree, might be overkill.

  • I wrote a couple little timing tests. I think the code can be simplified and made easier to understand by always having a posixify function, that's no-op on posix. That is faster. I also think checking for ':' and then running a regex that starts by checking for ':' is rather bogus, and just using the regex is only marginally slower AFAICT.

Edited by David Jencks

Merge request reports