Method visible_file_paths

atomic-repository/src/repository/materialize.rs:314–398

Compute the set of file paths visible on a view. Visibility includes the view's own changes AND all changes inherited through the parent chain. A draft view parented on dev sees dev's files without requiring an explicit insert. A file is visible on a view when: 1. It appears in the global TREE table (has been `add`ed). 2. Its inode has a graph position in the INODES table (has been `record`ed).

(&self, view_name: &str)

    /// entry) are NOT returned — they persist across switches as
    /// working-copy state.
    pub fn visible_file_paths(&self, view_name: &str) -> Result<HashSet<String>, RepositoryError> {
        let txn = self
            .pristine
            .read_txn()
            .map_err(|e| RepositoryError::Database(e.to_string()))?;

        let view = match txn
            .get_view(view_name)
            .map_err(|e| RepositoryError::Database(e.to_string()))?
        {
            Some(s) => s,
            None => return Ok(HashSet::new()),
        };

        // Use the FULL visible change set (own + parent chain) so that
        // draft views parented on dev see dev's files.
        let view_change_ids = collect_visible_change_ids(&txn, &view)?;

        // Walk TREE and keep paths whose introducing change is in the log.
        let mut paths: HashSet<String> = HashSet::new();
        let tree_iter = txn
            .iter_tree()
            .map_err(|e| RepositoryError::Database(e.to_string()))?;

        for result in tree_iter {
            let (path, inode) = result.map_err(|e| RepositoryError::Database(e.to_string()))?;
            if let Some(position) = txn
                .inode_position(inode)
                .map_err(|e| RepositoryError::Database(e.to_string()))?
            {
                if view_change_ids.contains(&position.change) {
                    paths.insert(path);
                }
            }
        }

        // REV_TREE recovery: a view is a FILTER over the global graph — every
        // node it exposes already lives in the graph, and TREE is just a
        // single-valued bookkeeping index over that graph. When two inodes
        // claim the same path (cross-view creates, a materialization
        // name-conflict), iter_tree can only expose the one binding — so a
        // switch used to classify a path that the target view's filter DOES
        // render as "absent from the new view" and silently DELETED it (see
        // `switch_file_loss_tests`). Re-insert any path that the filter
        // renders: some REV_TREE-claimed inode whose introducing change is
        // visible on the view AND alive under that filter — the same
        // predicate the materializer's name-conflict detection uses.
        {
            use atomic_core::pristine::TreeTxnT;
            let mut by_path: std::collections::HashMap<String, Vec<Inode>> =
                std::collections::HashMap::new();
            if let Ok(pairs) = txn.iter_rev_tree() {
                for (inode, path) in pairs {
                    by_path.entry(path).or_default().push(inode);
                }
            }
            for (path, inodes) in by_path {
                if paths.contains(&path) {