Im laufenden Betrieb gehe ich (mit Mercurial) bei neuen Versionen immer so vor, daß ich irgendwann einen Clone des Repos für die neue Version anlege und fortan in (mindestens) zwei Repos arbeite. Die neue Version bekommt deshalb schon ein neues Repo, damit die gesamte Build-Struktur für die alte Version unverändert weiterarbeiten kann (schließlich ist es zu diesem Zeitpunkt noch eine Weile hin bis zum Release der neuen Version). Kommt dann die neue Version raus laufen beide Systeme parallel weiter bis die alte Version eingestellt wird.
Die Repos sind durch ihre gemeinsame Versionshistorie ja immer noch verbunden und es lassen sich auch weiterhin noch Bugfixes aus der alten Version in die neue mergen, solange nicht massive Strukturänderungen dies erschweren. Insofern verliere ich durch die getrennten Repos keine Funktionalität, die ich mit Branches innerhalb eines Repos hätte. Es erhöht meiner Meinung aber deutlich die Übersicht. Sherlock's Grafik empfinde ich in diesem Zusammenhang auch eher als abschreckendes Beispiel (@Sherlock: no offence!). In meinen Repos entstehen solche Verzweigungen fast ausschließlich durch Implementierung von Features, das Beheben von Bugs oder das Tagging des Build-Systems - und sie werden immer lokal aufgelöst. Auf den zentralen Server-Repos gibt es keine multiple heads.
Ich bin kein Mercurial Experte, aber das hört sich irgendwie nicht sehr nach einer sinnvollen Strategie an. Für sowas gibts doch Branches und Tags.
Du scheinst auch nur allein mit dem VCS zu arbeiten, sonst würd dich so einen Commit Graph ziemlich kalt lassen, da hab ich schon wilderes gesehen.
Außerdem gibt's immer die Anzeigeoption "only current branch".
Da sich ja inzwischen für Git entschieden wurde, werf ich einfach mal ein Stichwort in den Raum:
Git flow