rojo 7.6.1

Enables professional-grade development tools for Roblox developers
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

//! This module defines the instance snapshot subsystem of Rojo.
//!
//! Snapshots define a way to define the instance tree of a project as a pure
//! function of the filesystem by providing a lightweight instance 'snapshot'
//! type, a method to generate minimal patches, and a method that applies those
//! patches.
//!
//! Changes in Rojo go through a pipeline of transformations once they hit the
//! snapshot subsystem.
//!
//! 1. Instance snapshots are generated by Rojo's snapshot middleware,
//!    representing a set of instances and their metadata. These will
//!    usually contain data that hasn't actually changed, and how coarsely
//!    the snapshots happen is defined outside this part of the code.
//!
//!    See `src/snapshot_middleware` for implementation.
//!
//! 2. Input snapshots are turned into `PatchSet` objects by Rojo's diffing
//!    algorithm via `compute_patch_set`. This operation doesn't mutate the
//!    instance tree, so work at this point can be thrown away.
//!
//!    `PatchSet` prescribe what changes need to be applied to the current
//!    tree to get the next tree. It isn't useful for describing those
//!    changes after the fact, since Rojo needs to assign IDs to created
//!    instances, which happens during patch application, not generation!
//!
//!    See `src/snapshot/patch_compute.rs` for implementation.
//!
//! 3. Patch sets are applied to the tree with `apply_patch_set`, which
//!    mutates the relevant instances. `apply_patch_set` returns a new
//!    object, `AppliedPatchSet`. Applied patch sets describe the transform
//!    that was applied, and are suitable for cases where another tree needs
//!    to be synchronized with Rojo's, like the Rojo Studio plugin.
//!
//!    See `src/snapshot/patch_apply.rs` for implementation.
//!
//! The aim with this approach is to reduce the number of bugs that arise from
//! attempting to manually update instances in response to filesystem updates.
//! Instead of surgically identifying what needs to change, we can do rough
//! "damage-painting", running our relatively fast snapshot function over
//! anything that could have changed and running it through a diffing function
//! to minimize the set of real changes.
//!
//! Building out a snapshot reconciler is mostly overkill for scripts, since
//! their relationships are mostly simple and well-defined. It becomes very
//! important, however, when dealing with large opaque model files and
//! user-defined plugins.

#![allow(dead_code)]

mod instance_snapshot;
mod metadata;
mod patch;
mod patch_apply;
mod patch_compute;
mod tree;

pub use instance_snapshot::InstanceSnapshot;
pub use metadata::*;
pub use patch::*;
pub use patch_apply::apply_patch_set;
pub use patch_compute::compute_patch_set;
pub use tree::*;

#[cfg(test)]
mod tests;