DAG rendering
If you don’t know what DAG means... lucky you! You’re probably a happy developer focusing on solving your own software problems, instead of delving into nitty-gritty version control details.
But if you’ve been in the coding community for the last 3 years or so, you’ve probably heard of “DAG oriented” distributed version control systems, such as Git. (I won’t include Mercurial here since it is, theoretically, a delta-based system according to the now famous "Getting Git" from Scott Chacon .)
DAG, which stands for “Directed Acyclic Graph”, is the underlying data structure that Git, and other SCMs, use to store the different versions you create.
While the DAG concept applies to the underlying structure, if you diagram the way changesets (“commits” in Git jargon) evolve, you’ll also get a beautiful tree that is... hey, acyclic too!
Painting trees
We’re working hard on the upcoming Plastic SCM 4.0 release, with a bunch of features under consideration -- from core changes to an even better merge to new visual tools, including a new BranchExplorer.
Today I’m going to share some of the concepts we’re using to render the evolution of the repository, the “changeset evolution” (or “commit evolution” if you prefer). This will help you understand the differences from Plastic SCM 3.0 and also illuminate the best way to render DAG-based version history.
It all started here
The diagrams below show some of our ideas for simplifying the display of version history, so that “what you draw on a blackboard to communicate with your colleagues” can become an interactive diagram, our BranchExplorer.
Since a good number of our new users have Git and Mercurial backgrounds, we thought that diagrams like these would make them feel more “at home”. Plastic SCM 4.0 will introduce some of these display strategies, which are similar to those of the most used DVCSs out there.
From paper to pixels – take 0
Here is one of the initial screenshots, similar to the conceptual diagrams above, but now implemented as an interactive graphic.
Zooming out, you can see a wider diagram in “DAG mode” (not a high-quality rendering, though):
Painting labels (or tags)
We’re also playing with some ideas to render labels in a more visible and interactive way than in Plastic SCM 3.0:
In Plastic SCM 4.0, labels will be fully clickable. Wewill also render them in such a way that you get some additional information even before clicking, such as when the same “changeset” has more than one label.
Going distributed
I don’t want to unveil all the details yet, so consider the next two as “spy photos” like the ones that show up on car magazines when a new model is still under development. (You know, you can get most of the details if you look carefully :P)
Right now I’ll just show some alternatives we’re working on with very preliminary screen shots. The following screen shot (which looks quite arcane to me now) includes some of the new labeled-changeset display along with information about different replication sources.
And finally, a much more polished screen shot quite evolved from the previous one (but we’re still not finished with BranchExplorer development!).
Wrapping up
In future posts, coming soon, long-term Plastikers will discover a bunch of forthcoming changes, while newcomers will still be able to see (and comment on!) some alternatives for diagramming repository evolution for a distributed version control system.
Stay tuned.
0 comentarios: