Menu
▾
▴
#360 preview in place?
people are suffering because their large project directories take a long time to copy when previewing. Maybe they should be allowed to preview without copying, if they think it's best.
This is closely related to "running background jobs in place", https://sourceforge.net/tracker/index.php?func=detail&aid=3473565&group_id=366300&atid=1527388.
Discussion
Anonymous
The downside of previewing in place, of course, is I don't know what to do about the problems that copying addresses. There are two main ones, I think.
First, that make operations aren't necessarily reversible. If someone tries out an operation in preview, and then decides against it and doesn't save the changes, it can leave the directory in a messed-up state and the page will not have correct project files on it, even though the changes were never saved. This can be very hard to come back from, or tedious, for instance if a whole bunch of unwanted files have to be removed.
Second, the great strength of wikis is their collaborative nature, in other words that they are fundamentally multi-user systems. If two or more people are working on overlapping sets of projects in preview, their changes would get mixed together in the working directory, or they would get stuck taking turns changing source files back and forth from one editor's version to another and remaking lots of downstream products every time. This would probably be lots more frustrating than waiting for a copy operation to start the preview session. And, of course, each person's unsaved changes could cause harmful side effects in the working directory, which would cause great frustration to the other editors, and would sabotage the saved copy as well.
Even with just one person editing, on a wiki that other people look at, maybe even the public, the editor's make jobs and the saved project's make jobs could end up running during the same time period and conflict with each other. And I suspect that the risk of causing trouble in the saved project, on a wiki that's used to publish things, would have a chilling effect, making people afraid to edit, and leading to a situation where people would avoid using the wikis.
All that said, the upside is that there are a lot of projects that have only one author, and even more that have only one editor at a time, and the long wait to start a preview session is a real problem, and is very often an unnecessary precaution.
In part, we have been waiting for copy-on-write, or at least I have.
Here's an idea I've been thinking about for years, and I now want to write it down here.
The idea is to not copy anything into the preview directory by default. When a file is posted by a submit command, of course it gets put into the preview directory. Other files get there because make links them, with a rule like
%:
/bin/ln $(PERSISTENT_VERSION)/$@ .
"%:" is a special, bottom-of-the-barrel rule in make, and this would work for many use cases. But there are also a lot of potential problems.
For example, do we want to give % a dependency (and would that mess up its specialness)? As written now, if the persistent directory is updated, we will get a newer version (compared to preview start) sometimes. There seems no way to get it never (except for real copy on write).
Even hairier, in my opinion, is the problem of chaining. I'm pretty confident that make won't always let this play well with implicit chaining. Plus, we have the problem that some projects are not really well structured (they rely on implicit run-R over and over, and so files have to be remade in order). These projects will need to (at least) be edited to add run-R explicitly to a lot of rules before this would work.
Ticket moved from /p/workingwiki/feature-requests/55/