I think a config file to change certain settings, like default branch name, check interval, and setting default username and email like #21 suggested, would be very helpful. Could be in your home directory called .dura in a format similar to a .gitignore.

I was running dura yesterday and it was working great. I think I accidentally closed the terminal it was running in and re-opened it, and now when I run dura serve I get this error:

$ dura serve
pid: 2285
Wrote /Users/dan/.config/dura/config.json
Shutting down because other poller took lock: None

My first thought was maybe I had another dura running but I don't think I do:

ps aux | grep dura
dan               2168   0.0  0.0 407963440    416 s001  R+   10:02AM   0:00.00 grep dura

Running dura kill didn't help either, I still get the same error when running dura serve.

Tests broke in #66 but we didn't catch it because our CI/CD pipeline doesn't run cargo test. This also enables tests on all platforms.

Ping @JakeStanger

closes #72

@drupol This definitely seems like a NixOS environment issue. Can you take a look? On Ubuntu it's usually solved with installing some C/C++ tools, like gcc. Not really sure about NixOS.

https://github.com/tkellogg/dura/runs/4750159031?check_suite_focus=true

The current CLI is fine, but the need to be in the current directory for some operations is a little annoying. The current implementation also makes it difficult to expand for more features (such as the WatchConfig fields added in #49 ).

I would suggest initially migrating the current code to use Clap or similar.

Commands could then be updated to the something like the below format:

dura serve # can be left as-is

# these default to cwd
dura watch [dir] [--include <includes>] [--exclude <excludes>] [--max-depth <depth>]
dura unwatch [dir]
dura capture [dir]

This works towards implementing features discussed in #3. It is still using the config.json format at the moment. I'll pick up discussion in #28 for migrating to a human-friendly format.

You can now eg navigate to ~/Programming and run dura watch to watch the whole directory recursively. The program will scan each child dir until either a repo is found or the max depth is hit.

Includes, excludes and the max depth can be manually tweaked in the config.json file.

If include is non-empty, then exclude is ignored.

Example config which includes two repos, one at Programming/dura and the other at Programming/unity/my-game:

{"pid":27814,"repos":{"/home/jake/Programming":{"include":["dura", "unity/my-game"],"exclude":[],"max_depth":255}}}

Example config which excludes all repos inside Programming/third-party:

{"pid":27814,"repos":{"/home/jake/Programming":{"include":[],"exclude":["third-party"],"max_depth":255}}}

I use git branch often, so I don't want to have hundreds of dura-HASH branches in the output, but I don't mind another static branch next to the master and staging. Is it possible to have just one dura branch, but keep snapshotting everything? I know that filtering out dura-HASH branches would be a solution to my problem, but still, I would like the single branch mode better.

P.S.: I'm very executed about this project for I've developed a habit of making a temporary commit every few minutes over the years, but your solution is better because it's automated ❤️

Last night I made a change to log JSON to ~/.config/dura/logs/. However, writing to stdout has a lot of advantages when running with other tools, like systemd.

• Print to stdout by default
• Print to file if --log-file is specified

• MacOS Monterey 12.1 (21C52) (Intel)
• rustc 1.57.0 (f1edd0429 2021-11-29)

On commit f4d552da1f92f3d5ad85de483f2faa0a3d2efa65.

Steps executed:

• brew install rustup
• rustup-init
• cargo install --path .
• RUST_BACKTRACE=1 dura serve

And got:

pid: 62355
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/config.rs:63:14
stack backtrace:
   0: rust_begin_unwind
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/panicking.rs:517:5
   1: core::panicking::panic_fmt
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/panicking.rs:100:14
   2: core::result::unwrap_failed
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/result.rs:1616:5
   3: dura::config::Config::save
   4: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
   5: tokio::park::thread::CachedParkThread::block_on
   6: tokio::runtime::thread_pool::ThreadPool::block_on
   7: tokio::runtime::Runtime::block_on
   8: dura::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Hi, just wanted to share that Dura is now available on Homebrew, so Mac users can install it with:

brew install dura

Homebrew precompiles binaries for both x86-64 and arm64, so installation is pretty much instant 🎉

Ref: https://github.com/Homebrew/homebrew-core/pull/106554

Hi, This adds the commit sha256 sum to the end of the artifact names to differentiate between versions.

BTW, do you have any plans for a release schedule? I can create a workflow for automatic releases. I also added a pre-requisite for that in this commit: (https://github.com/tkellogg/dura/commit/1a09368649347e7ebbcfb40d6ed96a3f1f158fff)

Thanks

Reduce disk I/O by moving most directory listing to a probabalistic cache approach. For one, I don't want to wear out disks by constantly accessing them. Spinning disks are especially problematic because latency can be quite high.

This introduces CachedDirIter which replaces usages of fs::ReadDir. It's an enum that can either wrap a fs::ReadDir or represent a cache hit by iterating a vector af paths. The cache itself is a Trie, so it shouldn't take that much memory to hold in memory all paths under $HOME, for example. The cache lives at program scope and is passed down into where it's needed.

Cache invalidation is a problem, though. I don't want to refresh the entire Trie all at once, but I also want guarantees that a new directory will be recognized within a certain time limit, e.g. within 10 minutes. Here I take a probabalistic approach. Each individual directory entry is invalidated independently. On any given pass, there's an X% chance that a single directory will be invalidated. X is calculated such that caches will be invalidated within some maximum time bound (10 minutes) 95% of the time. In the remaining 10% of cases, they're force-invalidated at the 10 minute mark.

The duralite sub-project has been about reducing dura's presence on host machines by utilizing as few resources as possible. I don't want people to not use dura because "my computer runs slow with it". Something I've been observing is that, as I reduce these I/O-intensive bottlenecks, dura uses even more CPU. In a follow-up PR I want to add some strategically placed thread::sleep's to spread out the CPU usage evenly throughout the entire 5 second polling interval.

Repro

• Run dura serve
• Create a new repo, e.g. with cargo new, and make changes without committing
• Check the stdout log, there should be errors that look like:

{"target":"dura::poller","file":"src/poller.rs","name":"event src/poller.rs:41","level":"Level(Info)","fields":{"message":"info_operation","operation":{"Snapshot":{"error":"reference 'refs/heads/master' not found; class=Reference (4); code=UnbornBranch (-9)","latency":0.000267355,"op":null,"repo":"/Users/timkellogg/code/oss/syndr"}}},"time":"2022-11-28T14:27:18.611085+00:00"}

Expected behavior

This happens when there's no first commit. Normally the branch name is dura_{base_commit_hash}, in this case we could make it a constant dura_unborn or dura_init.

This also means that the first commit in sequence might not have a parent, which may cause other problems.

It takes seconds to run the command. Not sure the necessity of this at all, and it may actually cause bad habits and behaviors that could lead to other sloppiness and waste in other areas of your life.

I'm new to using dura, so I might be doing something wrong. I've had dura running in the background for the last 30min or so (e.g. via dura serve &). See terminal output below;

@silvergasp ➜ /workspaces/embedded_controller (main ✗) $ ps
  PID TTY          TIME CMD
 3596 pts/0    00:00:00 bash
 5004 pts/0    00:00:00 dura
 7420 pts/0    00:00:00 ps
@silvergasp ➜ /workspaces/embedded_controller (main ✗) $ git branch
* main
@silvergasp ➜ /workspaces/embedded_controller (main ✗) $ 

Note that the only branch is the 'main' branch.

Note that this is running in Github codespaces on the latest version of ubuntu;

No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.4 LTS
Release:        20.04
Codename:       focal

Automated changes by the update-flake-lock GitHub Action.

Flake lock file updates:

• Updated input 'flake-utils':
    'github:numtide/flake-utils/1ed9fb1935d260de5fe1c2f7ee0ebaae17ed2fa1' (2022-05-30)
  → 'github:numtide/flake-utils/5aed5285a952e0b949eb3ba02c12fa4fcfef535f' (2022-11-02)
• Updated input 'nixpkgs':
    'github:nixos/nixpkgs/90cd5459a1fd707819b9a3fb9c852beaaac3b79a' (2022-06-11)
  → 'github:nixos/nixpkgs/652e92b8064949a11bc193b90b74cb727f2a1405' (2022-12-22)
• Updated input 'rust-overlay':
    'github:oxalica/rust-overlay/e04a88d7f859ae9ec42267866bb68c1a741e6859' (2022-06-12)
  → 'github:oxalica/rust-overlay/fd2740316bacb3e0106381c325e0bb90d6790aeb' (2022-12-25)
• Updated input 'rust-overlay/flake-utils':
    'github:numtide/flake-utils/bba5dcc8e0b20ab664967ad83d24d64cb64ec4f4' (2021-11-15)
  → 'github:numtide/flake-utils/c0e246b9b83f637f4681389ecabcb2681b4f3af0' (2022-08-07)
• Updated input 'rust-overlay/nixpkgs':
    'github:NixOS/nixpkgs/8afc4e543663ca0a6a4f496262cd05233737e732' (2021-11-21)
  → 'github:NixOS/nixpkgs/14ccaaedd95a488dd7ae142757884d8e125b3363' (2022-10-09)

Running GitHub Actions on this PR

GitHub Actions will not run workflows on pull requests which are opened by a GitHub Action.

To run GitHub Actions workflows on this PR, run:

git branch -D update_flake_lock_action
git fetch origin
git checkout update_flake_lock_action
git commit --amend --no-edit
git push origin update_flake_lock_action --force