In the 
, we have:
first box: excerpt from index page, this box shows just ONE website (there si one of these for each site.
pc.com == site name
Arrow points to the umbrella version that gathers together versions of many different packages
Next 5 numbers are the versions of each of the pkgs that are included in the highlighted umbrella version (with one-word shortnames of each above them).
"New version 144" is a link to *create* a new version, that will become 144.
---
Second box: what you get when you click on create new version
Each line represents one package avaialbe to include int he umbrella version
Drop-downs are pre-populated with the version number (for all versions 1...N) with the checkin comment for that version.
The final column lets you select which branch you want to take a version from - if you change any value in this column, it triggers an auto-refresh of the page, so that the main drop-down for that row can be re-populated appropriately.
Where packages have no branches, they just have the plain text "main" with no drop-down to select another branch.
I (KenSchalk) have also been thinking about how vupdate could work with branches. Suppose you have some system made up of many individual packages. You probably want to think about branches in terms of the whole system. The divergence in a given branch might only apply to certain packages. In others, you might want to stay with the main line. You'd use vbranch to create branches in those packages which need to diverge, but not in those packages where you're staying with the main line.
The way I've been visualizing this is as though each branch is like a thread that runs through the whole package, as in this diagram:
Let's suppose vupdate has some option to follow branches.
- In package B, if the the current version is 2, and you do "vupdate -branch blue", then it would update the import to 3.blue/2, the latest version on the blue branch. Doing "vupdate -branch red" or "vupdate -branch green" would instead get you version 5.
- In package C, if the current version is 6, "vupdate -branch red" would update to 8.red/1, but "vupdate -branch blue" or "vupdate -branch green" would update to version 9
- In package A, regardless of which branch you specified you would be version 8 because there are no branches for this package.
Branches in Vesta today work like a tree: they fork off from the trunk and becom their own separate lineage from that point forward. To make this branch threading idea work, we'd need some way to mark the successor version to a branch on the trunk. This might be created by merging the changes from the branch into the trunk, promoting the latest version in the branch onto the trunk, or even just declaring the branch finished or obsolete and dropping whatever changes it had. This would make branching act more like a DAG than a tree. The point is, vupdate would need some way to follow the thread out of the branch and back onto the trunk.
I actually think this feature is useful for another reason too: the output of "vlatest -b" shows all branches, which is really too much information. Branches which have been "closed" in this sort of way (my merging, promotion, or declaration) aren't really interesting any more. The user is more interested in the "open" branches: those which represent divergences under active development, or at least actively being used, which probably require some reconcilitation.
Another thing to consider is that with this branching/converging strubture, we will probably want some way to view the full history graph. Something like monotone-viz.