Hello TinyTree - TinyTreeSkip to content<br>As I started sharing TinyTree with folks, I started getting a lot of questions about this project:What is TinyTree? What is a neo-forge? What is a monorepo? Why SCM and not VCS?<br>Let me walk you through the problem I am trying to solve and the way I plan to solve it.First-class monorepos<br>Up until now, monorepo tooling in the wild has still been lacking. It remains a $BIG_TECH-exclusive technology. If you talk to anybody who worked there, they will tell you how superior that setup is. The more avid users will also tell you why it is better.It is because dedicated teams work full time to keep a single repository healthy.They build custom version-control tooling when users feel blocked. They build highly scalable servers to unblock automated commits. They build custom code review tools and countless integrations with internal services to provide additional context to authors and reviewers. They build custom virtual file systems for source code with first-class build tool and IDE integration.Most importantly, they have the $BIG_TECH money to keep funding those teams and keep multiplying engineering productivity.Monorepos make it easier for these DevX teams to function because they have a single place to pour their resources into, instead of tens of thousands of Git repos scattered across different namespaces. In turn, these DevX teams make it easier for their fellow engineers to do their jobs.I want to bring that ecosystem to the masses. Not just by building cool technology, but also by building an ecosystem around that technology, starting with a functional commercial business dedicated to promoting monorepo technologies. That is TinyTree in a nutshell.The how<br>So what is special about a monorepo designed for large source trees with many boundaries?<br>Narrow clones<br>The first thing is that you will not need most of that code on a day-to-day basis. You will only need the pieces that you care about. It is extremely inconvenient to clone the entire Linux.git repository just to work on one file. Because of that, a TinyTree monorepo will never start as a full clone.Instead, we use narrow clones. Inside a narrow clone, the working copy of the repo is defined by a sparse checkout, and the downloaded change history is shallow. You get to craft your own sparse checkout profile, also known as a view, and we take care of the rest.These views are defined in config files and tracked inside the monorepo itself. The config files are written in Starlark and can be generated using our tt view create CLI subcommand. Users without a default view configured will be able to discover views their teammates have already crafted for them.A narrow checkout should make those boundaries obvious:$ tt view client<br># switched to view "client"<br># checked out:<br># client/**<br># shared/api/**<br># shared/proto/public/**<br># hidden:<br># server/**<br># infra/**<br># history downloaded:<br># 184 commits
$ tt log --oneline<br># f3c2a18 client: import gh repos<br># 9bd71e4 client: add onboarding view<br># c8aa421 shared: publish public API types
$ tt view server<br># switched to view "server"<br># checked out:<br># server/**<br># shared/api/**<br># shared/proto/public/**<br># hidden:<br># client/**<br># web/**<br># history downloaded:<br># 231 commits
$ tt log --oneline<br># 73a1b5c server: import auth service<br># 11d2f09 server: wire request router<br># c8aa421 shared: publish public API types<br>By being narrow by default, we enable many more use cases that are typically not possible with a full-clone setup. More things can be added to the monorepo simply as new directories.For example, instead of using tags for versioned releases, users can do something like tt cp src release/1.0.1 to create a new release using a copy of the current source tree at HEAD. Releases are never included in the working copy of your view unless you explicitly configure them to be included. As we gradually move our backend off Git into TinyTree’s own data model, tt cp can add additional metadata to track the copy relationship so that something like tt log -- release/1.0.1 will also give you the history from src at the cutoff point.Access control<br>So how are you keeping secrets in this repo?<br>The secret is just a config file under .tt, but that file is only included in an admin-only view. That means only users with admin roles can check out the file, inspect its history, and modify it.This is where .tt gets special system .scl files. Unlike tree-local SRC, .tt/*.scl is system configuration: user roles, privileged views, and other repo-level control-plane state.role(<br>name = "admin",<br>users = [<br>"son",<br>],<br>groups = [<br>"platform-admins",<br>],
view(<br>name = "admin-only",<br>include = [<br>".tt/access.scl",<br>".tt/secrets/**",<br>],<br>roles = [<br>"admin",<br>],<br>For everybody else, those files simply do not exist in their view. They cannot check them out by accident, browse their history, or send a change that modifies them. The boundary is declared as source, reviewed as source, and enforced through the view they are allowed to work...