From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: resolving ambiguity in action stamps Date: Sun, 14 Sep 2014 13:03:55 +0200 Organization: Organization?!? Message-ID: <8738butqec.fsf@fencepost.gnu.org> References: <87wq9841zx.fsf@uwakimon.sk.tsukuba.ac.jp> <20140913053525.GA15582@thyrsus.com> <87tx4c3t4k.fsf@uwakimon.sk.tsukuba.ac.jp> <20140913.092630.2301242291023129455.hanche@math.ntnu.no> <20140913105058.GA16776@thyrsus.com> <87r3ze4pw6.fsf@uwakimon.sk.tsukuba.ac.jp> <20140914105531.GA30576@thyrsus.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1410692688 19565 80.91.229.3 (14 Sep 2014 11:04:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 14 Sep 2014 11:04:48 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 14 13:04:41 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XT7bj-0004UE-9U for ged-emacs-devel@m.gmane.org; Sun, 14 Sep 2014 13:04:39 +0200 Original-Received: from localhost ([::1]:53611 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XT7bi-000560-Tr for ged-emacs-devel@m.gmane.org; Sun, 14 Sep 2014 07:04:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45157) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XT7bP-0004v7-Qq for emacs-devel@gnu.org; Sun, 14 Sep 2014 07:04:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XT7bF-0003NT-9B for emacs-devel@gnu.org; Sun, 14 Sep 2014 07:04:19 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:52588) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XT7bF-0003NL-3T for emacs-devel@gnu.org; Sun, 14 Sep 2014 07:04:09 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XT7bD-0004Oi-Gd for emacs-devel@gnu.org; Sun, 14 Sep 2014 13:04:07 +0200 Original-Received: from x2f3fb81.dyn.telefonica.de ([2.243.251.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 14 Sep 2014 13:04:07 +0200 Original-Received: from dak by x2f3fb81.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 14 Sep 2014 13:04:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 32 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: x2f3fb81.dyn.telefonica.de X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) Cancel-Lock: sha1:tyhy7myJBql9+DwORESs78Li7Bs= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:174286 Archived-At: "Eric S. Raymond" writes: > The second problem is that it's not future-proof. Someday we might > have to change VCSes again; git is the *fifth*, after RCS CVS Arch > bzr. Being friendly to Arch mirrors does not imply that Emacs actually went through Arch. > It would be unwise to assume that nobody will ever have a better idea. > > At that time it would be a Really Good Thing if as few of our commit > refs as possible are opaque magic cookies - and in order to translate > them to whatever new commit-ref format we'll *still* have to go > through a semantic equivalent of revision stamps! > > Thus, it seems best to me to just land on a VCS-independent and > human-readable version-stamp format and stay there, treating > VCS-specific commit-refs as a practice flaw to be avoided. I disagree. The whole point of the repo conversion is to make it more convenient for the _current_ version control system to work with the history and you are proposing to change to a format that is a nuisance for _every_ version control system rather than to every version control system _apart_ from the one being in active use. When we change to something else but Git for the canonical VCS, we'll want to convert all those references to whatever we are moving to in order to make dealing with history reasonably nice. -- David Kastrup