What does Fossil offer for getting a structural mindmap of branches?

(1) By anonymous on 2022-05-12 15:07:50 [link] [source]

I feel like I'm getting lost in a repository with multiple level of branches like:

trunk
    branch1
        branch1-1
        branch1-2
    branch2

/brlist in the web interface provides a linear listing that does not reflect the nesting of branches

The CLI command fossil branch list doesn't provide such insights either.

I did a couple of forum searches and the only thing related to this that I could find was this thread

But it's one year old and contains non-finalized reflections only.

What's the current status of fossil regarding this? If fossil still doesn't provide options for this need, how do you guys cope with it? Do you have any specific VCS agnostic branching strategies that you follow to avoid getting lost in a reasonably big repository with multiple nested branches?

(2) By Stephan Beal (stephan) on 2022-05-12 15:18:37 in reply to 1 [link] [source]

But it's one year old and contains non-finalized reflections only.

They were simply musings about the poster's request, not plans for any future features.

What's the current status of fossil regarding this?

The same as it was then: fossil does not track branches, it tracks versions. The /timeline is the closest thing you'll find (in fossil itself) for visualizing branches in a human-friendly way.

It would certainly be possible for someone interested in the problem to export branch relationships using pikchr or DOT or some similar format, but nobody's stepped up to take that on.

(3) By anonymous on 2022-05-12 15:46:23 in reply to 2 [link] [source]

The /timeline is the closest thing you'll find (in fossil itself) for visualizing branches in a human-friendly way.

Indeed, but what are the CLI options? I've read the help for fossil timeline and tried to experiment with -F %p option, but I am confused:

%p  phase: zero or more of *CURRENT*, *MERGE*,
           *FORK*, *UNPUBLISHED*, *LEAF*, *BRANCH*

What exactly each of these things mean?

(4) By Stephan Beal (stephan) on 2022-05-12 18:36:30 in reply to 3 [link] [source]

Indeed, but what are the CLI options?

There aren't any for what you're asking about. The /timeline is the only feature we have which is close to what you're asking for. Patches to remedy that will be thoughtfully considered.

What exactly each of these things mean?

Leaf: a checkin with no children on the same branch.
Branch: it's a branch point (or the first checkin of a branch point - i'm not sure which).
Fork: is very similar to a branch. See the thread you initially linked to for the distinction.
Merge: it's a merge point.
Current: is only relevant for a checkout and denotes the checked-out version.
Unpublished: only relevant for private branches and private bundle imports, neither of which are commonly used. Private branches are "unpublished" until they're merged into a public branch or explicitly published with the publish command.

In any case, that info is not going to help you get an overview of branches (or won't help much).

(5) By Andy Bradford (andybradford) on 2022-05-13 04:21:58 in reply to 4 [link] [source]

> Fork:  is very  similar to  a branch.

I like to think of a fork as the natural and primitive concept caused by
a split in the timeline where two commits are made against the same node
in the trunk. Each side of the fork has the same name as the parent.

A branch is a fork but which  has one of children named differently than
the other. So a branch is like a fork but named.

Furthermore, the name of  a branch is just a tag on  a given commit that
propagates to descendents.

Andy

(6) By mattwell on 2022-05-15 12:26:46 in reply to 1 [source]

I'll describe below how I deal with this but first, I think what you are asking for, a timeline that is not tied to time, would be phenomenally useful. You could probably do this with a little scripting to generate a .dot file and then run graphviz to get the graph you want. It would be excellent if this was built in to fossil.

As for how I personally solve this, my approach might be frowned on by fossil purists but I need to get things done and this works for me. Maybe my approach will be useful to others.

The problem statement:

In complex development, especially with multiple contributors, the timeline can get messy. Long running development of a new feature happening in parallel with fixes and other smaller features is intrinsically complicated. The methodology I learned with subversion and used for years with fossil was to periodically merge in changes from trunk to my long running development. But this creates a spaghetti-like history and the parallel development is now mixed in with other fixes and new features. If you don't like clutter this methodology will definitely frustrate you.

My solution (not original, not perfect, but it works for me):

Do NOT merge from trunk into the development branch.
Every once in a while update to the base of the dev branch, merge the tip of the dev branch and commit. This squashes the dev branch into a single commit.
Go to the tip of trunk and cherry pick the new squashed branch and commit to a new branch.
Rename, close and hide branches as needed to get back to useful, succinct branch names.
Stand back and admire your tidy, complete and easy to understand timeline :)

NOTES:

You can squash multiple commits into a series of more meaningful commits instead of squashing to a single commit. I've found that a single commit works fine for me.
The beauty of fossil here is that the full real history is available - just unhide the old branch. I absolutely love how fossil tracks all changes to branches, tags etc. As best I can tell other popular tools do not do this.
You can use private branches for the intermediate squashed branches to reduce clutter even more but I prefer to keep the details hidden but available.
Yes, I know what feature in another SCM tool this resembles.
Yes, this process can be challenging if you happen to run into conflicts but you were going to have to deal with those conflicts one way or another. If you have complex conflicts you might need to do the process more often.