VCS comparison table
jnareb at gmail.com
Mon Oct 23 23:45:28 BST 2006
Matthew D. Fuller wrote:
> On Mon, Oct 23, 2006 at 10:29:53AM -0700 I heard the voice of
> Linus Torvalds, and lo! it spake thus:
>> I already briought this up once, and I suspect that the bzr people
>> simply DID NOT UNDERSTAND the question:
>> - how do you do the git equivalent of "gitk --all"
> I for one simply DO NOT UNDERSTAND the question, because I don't know
> what that is or what I'd be trying to accomplish by doing it. The
> documentation helpfully tells me that it's something undocumented.
gitk - git repository browser
Displays changes in a repository or a selected set of commits. This includes
visualizing the commit graph, showing information related to each commit, and
the files in the trees of each revision.
Historically, gitk was the first repository browser. It's written in tcl/tk
and started off in a separate repository but was later merged into the main
To control which revisions to shown, the command takes options applicable to
the git-rev-list(1) command. This manual page describes only the most
frequently used options.
Show all branches.
Which means that "gitk --all" means show whole DAG in graphical history viewer.
As in bzr there is no command (nor plugin) to clone whole repository,
I guess that the answer is that you can't do this. But perhaps
I'm mistaken, and you can do this in bzr-gtk/bzrk...
>> For example, how long does it take to do an arbitrary "undo" (ie
>> forcing a branch to an earlier state) [...]
> I don't understand the thrust of this, either. As I understand the
> operation you're talking about, it doesn't have anything to do with a
> branch; you'd just be whipping the working tree around to different
> versions. That should be O(diff) on any modern VCS.
For example if you decide to discard some changes completely, reverting
(this action in git is called 'rewind') branch to some previous revision.
And in git this operation is O(1), not O(diff).
BTW. The following question IIRC remained unanswered: can you easily
in bzr create branch off arbitrary revision (for example deciding that
stable branch should start two revisions back in history from development
>> and yes, performance does matter.
> I agree, and I currently find a number of places bzr doesn't hit the
> level of performance I think it should. I'm not convinced, however,
> that any notable proportion of that has to do with the abstract model
> behind it. And insofar as it has to do with the physical storage
> model, that can easily be (and I'm confident will be, considering it's
> a focus) ameliorated with later repository formats.
Some of physical storage models needs specific abstract model. I think
that git storage model is in this class.
>> The whole confusing between "bzr pull" and "bzr merge" is another
>> _technical_ sign of why branch-local revision numbers are a mistake.
> I consider it a _technical_ sign of a way of thinking about branches I
> prefer 8-}
Or _perhaps_ just the way of thinking about branches in the way you are
ShadeHawk on #git
More information about the bazaar