From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carl Worth Subject: Re: VCS comparison table Date: Tue, 17 Oct 2006 18:25:58 -0700 Message-ID: <871wp6e7o9.wl%cworth@cworth.org> References: <9e4733910610140807p633f5660q49dd2d2111c9f5fe@mail.gmail.com> <45357411.20500@utoronto.ca> <200610180246.18758.jnareb@gmail.com> <45357CC3.4040507@utoronto.ca> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Tue_Oct_17_18:25:58_2006-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: Jakub Narebski , Linus Torvalds , Andreas Ericsson , bazaar-ng@lists.canonical.com, git@vger.kernel.org X-From: git-owner@vger.kernel.org Wed Oct 18 03:26:17 2006 Return-path: Envelope-to: gcvg-git@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Ga0C8-0006Ys-SP for gcvg-git@gmane.org; Wed, 18 Oct 2006 03:26:09 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751224AbWJRB0E (ORCPT ); Tue, 17 Oct 2006 21:26:04 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751231AbWJRB0E (ORCPT ); Tue, 17 Oct 2006 21:26:04 -0400 Received: from cworth.org ([217.160.249.188]:60865 "EHLO theworths.org") by vger.kernel.org with ESMTP id S1751224AbWJRB0B (ORCPT ); Tue, 17 Oct 2006 21:26:01 -0400 Received: (qmail 24043 invoked from network); 17 Oct 2006 21:26:00 -0400 Received: from localhost (HELO raht.cworth.org) (127.0.0.1) by localhost with SMTP; 17 Oct 2006 21:26:00 -0400 To: Aaron Bentley In-Reply-To: <45357CC3.4040507@utoronto.ca> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.4 Mule/5.0 (SAKAKI) Sender: git-owner@vger.kernel.org Precedence: bulk X-Mailing-List: git@vger.kernel.org Archived-At: --pgp-sign-Multipart_Tue_Oct_17_18:25:58_2006-1 Content-Type: text/plain; charset=US-ASCII On Tue, 17 Oct 2006 21:00:51 -0400, Aaron Bentley wrote: > Jakub Narebski wrote: > > Well, that is another example while generation number is/can be global, > > any numbering of branches must be local-only. > > No. The numbering always follows the leftmost parent. So each revision > has a permanent (but non-unique) number. Aaron, thanks for carrying this thread along and helping to bridge some communication gaps. For example, when I saw your original two two diagrams I was totally mystified how you were claiming that appending a couple of nodes and edges to a DAG could change the "order" of the DAG. I think I understand what you're describing with the leftmost-parent ordering now. But it's definitely an ordering that I would describe as local-only. That is, the ordering has meaning only with respect to a particular linearization of the DAG and that linearization is different from one repository to the next. > > ...but that means that revision numers are totally, absolutely useless. > > Unless by some miracle of engineering, or adding namespace, they can be > > made unchangeable. > > No, because no one pulls unless they're trying to maintain a mirror of > the other branch, or else they decide to throw their local history away. If in practice, nobody does the mirroring "pull" operation then how are the numbers useful? For example, given your examples above, if I'm understanding the concepts and terminology correctly, then if A and B both "merge" from each other (and don't "pull") then they will each end up with identical DAGs for the revision history but totally distinct numbers. Correct? So in that situation the numbers will not help A and B determine that they have identical history or even identical working trees. So what good are the numbers? I can see that the numbers would have applicability with reference to a single repository, (or equivalently a mirror of that repository), but no utility as soon as there is any distributed development happening. -Carl --pgp-sign-Multipart_Tue_Oct_17_18:25:58_2006-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFNYKm6JDdNq8qSWgRAkQlAJ40yJru8GZZnYX2Jn7rE54nUh2nKgCfRSDK D6DF90+ufD1iBvgMLM5Q5y4= =8xso -----END PGP SIGNATURE----- --pgp-sign-Multipart_Tue_Oct_17_18:25:58_2006-1--