Is anyone else using branches with unrelated file trees? I know it's technically possible, but somehow it seems a little bit odd or potentially confusing.

For instance, I have a repository for configuration files. There's a branch for the MacOS config files, and a branch for the Linux configuration files, etc. There might be some similar directory layout between them, but otherwise they're completely independent. This way, I can clone the repository on each machine and checkout the correct branch for the OS.

Another more controversial example might be if you had a large project with extensive documentation, and you split the documentation into its own branch. If there were contributors who only worked on docs, they'd checkout the docs branch and not have to see any of the code.

Does this seem like a clever solution, or a recipe for problems? One reason it seems unsupported is that the file browser in the UI doesn't have a pulldown for changing the branch (you can alter the URL, of course), and the other views -- "Files in the top-level directory in any check-in" -- would be confusing if the branches were supposed to be completely separate directory trees.

Thoughts?

I guess the question is "why not just use different repos"?

If it's just you, it doesn't really matter - whatever floats your boat (and you can have multiple checkouts on disk at any one time on different branches).

If it's a group effort, you lose all the ability to set different levels of access and privileges, and have the disadvantages of isolated code structures without the benefits of independent management and availability of the same.

So I have no doubt that you can do as you suggest. But I can't think of a good enough reason as to why you would choose to, unless you were desperate for a monolithic repository archive while maintaining parallel hierarchies.

In which case, go for it.

But since "technically possible" and "good idea" are not the same thing, it will take some convincing before I'll be willing to show you how that can be done.

There's another example I brought up earlier -- using fossil to track changes to town bylaws. In that repo, I am keeping the trunk branch clean, showing only the bylaw changes. But I also wanted a place for documentation about the project, and possibly to add source code that I used to build the site. I stuck that in another branch of the same repository, so that the information could be available at /doc/<branch>/about.md (or whatever). I think the convenience of having it all in one repository outweighs the potential confusion.

I see zero practical value in having these two sets of files committed to the same repo, and multiple reasons not to.

I shouldn't have said completely independent. For my config file repo (for home directory dotfiles), there's a trunk branch with common files, and separate branches for each OS. It's possible that one of the OS branches will diverge entirely, and it's possible that I'll add more "common" files to the trunk, and merge them to the branches.

In that example, it's just me dealing with the changes, so this arrangement seems perfectly fine.

It brings me to my next point, though, which is that using Fossil to manage whole-system config archives is generally a bad idea.

Yes, I have another repo for /etc/ config files. That one has a shell script that runs install to copy each file into /etc/, with the correct permissions. It's much safer than symlinking...

If the doc writers have no business changing the code — or possibly even seeing it — then you need separate repos

That's a good point. Actually, I have yet to use fossil in a team environment, so I'm not sure what sort of permission issues would arise.

And if I checkout a branch named "macos" I get a different set of those files (and even the same files but different contents) than I get when I checkout "linux"? But then if I checkout "documentation" I only see the docs directory?

Actually, that's mixing up the two examples I gave.

Example 1 is the repo I use for dot files:

.bashrc
.profile
.tmux.conf
.vimrc
.config/whatever

There's a branch for macos and a branch for openbsd, linux, etc. The openbsd branch might not have .bashrc, and it'll have other stuff. Trunk has a few common files between them.

I just fossil up mac and not worry about other OS files cluttering the working tree. And I'm the only person managing it.

Example 2 was a hypothetical scenario where you have source code on trunk and documentation on a doc branch. That way, people who work on documentation would never accidentally commit something to trunk, because the working tree would make it obvious which branch they're on. I'd imagine it might be useful if you have a large amount of documentation, or a lot of churn, but you want to package it all for easy reference on the website. I don't know; maybe nobody would do that.

Yes, there could be permission issues. It's the same problem that any fossil project might have – committers can commit to any branch. How do you prevent a "developer" account from clobbering trunk? With fossil, it's left to the social realm.

Depending on what you're trying to accomplish, it seems like it might be better to separate the concerns into different directories in a single repository, than trying to separate the concerns through branches in Fossil.

In a previous iteration of my "/etc configuration repo", I used separate directories for each machine. But I was using mercurial, and I don't think it's possible (or at least not obvious) how to have separate file trees per branch (changes are tracked per file, not per tree). With fossil, it's dead simple.