From: "Eric S. Raymond" <esr@thyrsus.com>
To: "Stephen J. Turnbull" <stephen@xemacs.org>
Cc: Harald Hanche-Olsen <hanche@math.ntnu.no>, emacs-devel@gnu.org
Subject: Re: resolving ambiguity in action stamps
Date: Sun, 14 Sep 2014 13:12:11 -0400 [thread overview]
Message-ID: <20140914171211.GA2521@thyrsus.com> (raw)
In-Reply-To: <878ulm434v.fsf@uwakimon.sk.tsukuba.ac.jp>
Stephen J. Turnbull <stephen@xemacs.org>:
> Eric S. Raymond writes:
>
> > It is still a technical fact that no git translation containing SHA1s
> > can be built without passing through a VCS-independent representation
> > of commit refs on the way.
>
> Fact!? I would use the bzr revid, and insert the revid, SHA1 pair
> after I commit each new revision in git on Pass 1. What am I missing?
For one thing, variant forms of commit reference. Somewhere in there
we'll need the equivalent of a canonicalization pass for the references.
If you go the database-of-pairs route, what you're actually doing is
temporarily creating a VCS-independendent reference ID that mimics a
bzr reference number. A subtle point, I know - but in principle
there's no actual win in the database-of-pairs that you wouldn't also
get from unique inline reference cookies generated in an intermediate
pass.
In practise, the way my toolkit works, I basically have to have
something like a revision-stamp inline in intermediate versions (that
is, the database-of-pairs approach is out) even if it's massaged into
a SHA1 in the final version. This is because my tools are an ecology
of import-stream processors built on the assumption that the stream
captures all relevant metadata.
Your instinct may be to come back that this approach is too limiting,
but there are very good reasons for it (beginning with the cross-VCS
portability of the stream files) and 22KLOC of algorithmically dense
tool code built around those reasons. If you want a high-quality
conversion in reasonable time rather than an open-ended R&D project,
your odds of doing better are effectively nil.
> Speaking of databases: since AFAIK you're basically done creating git
> blobs and trees (ie, except for new commits to the public repo), I
> assume you are using a pre-primed object db when you run your
> conversion? If not, you should get a 20% speed up or so. You might
> be able to get a lot more speed up if you could just work with bzr log
> and git filter-branch. (That's a pretty crazy idea and quite possibly
> not at all worth the work even if possible. But let me throw it out
> there....)
It's not crazy, but it is too much work. I'd effectively have to throw
away the rest of my tools.
> > > Actually, I disagree. It would be a really good thing if they
> > > are precise. Do you really want to put anybody through the
> > > trouble of translating randomized format cookies, which may point
> > > to any of several commits, again? Then revising their scripts
> > > every time a new variant shows up?
> >
> > It has yet to be demonstrated that this is a problem in a real use
> > case. And, actually, I already checked this; the Emacs history
> > doesn't have any version-stamp collisions in actually referenced
> > revisions.
>
> That's not what I'm talking about. I'm talking about
> 2014/09/15!esr@thyrsus.com vs. 2014-09-15/esr@thyrsus.com vs.
> 9/15/2014!esr vs. .... People *will* handwrite those references,
> precisely because they're more or less human-readable.
Engineering is tradeoffs. Readability (which is a good thing)
comes with this price.
> > > Existence proof comes before characterization, please.
>
> Ie, I suppose you don't get any collisions in referenced revisions.
> But we know that there could be. Maybe "almost correct" is good
> enough for you, but I think Emacs deserves better from its VCS. Worse
> is not better when best already exists.
Engineering is tradeoffs. "Best" by what metric? Readability and
portability are not trivial features.
One significant disadvantage of building in SHA1s that I haven't mentioned
yet is that they make references brittle. Editing metadata invalidates
all hashes downstream of it invalid.
Yes, this is a real problem which I have experienced before in big messy
conversions like this one! So, we put up a brand shiny new repo - and
a few days (or weeks, or months) later someone spots a conversion bug
that has to be fixed.
It might be easy for you to say "oh, we just regenerate all the commit
references, then". Actually doing that is a nasty, picky job even
with best-in-class tools like mine, especially on a repo this size.
I'm not sure anyone on this list but me properly groks the complexity scale
of this conversion wgen they talk so casually about changing how
it's done. To get some idea, fetch
https://gitorious.org/emacs-transition/emacs-transition/raw/ca127b4e1a70cd17f2979b330b3f9dcedaf5bbd8:emacs.lift
and skim all 1018 lines of it - which doesn't count 2.5 Klines of program-
generated stuff included.
When I said this was the biggest, nastiest conversion I've ever done, I
wan't kidding. Nothing else has even come close.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
next prev parent reply other threads:[~2014-09-14 17:12 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-12 4:36 Everyone, please stop making my life more difficult Eric S. Raymond
2014-09-12 6:08 ` Eli Zaretskii
2014-09-12 9:55 ` Eric S. Raymond
2014-09-12 10:33 ` Eli Zaretskii
2014-09-12 10:49 ` Gregor Zattler
2014-09-12 13:05 ` Eli Zaretskii
2014-09-12 13:19 ` David Kastrup
2014-09-12 13:29 ` Eli Zaretskii
2014-09-12 13:55 ` Andreas Schwab
2014-09-12 14:12 ` Eli Zaretskii
2014-09-12 15:17 ` Eli Zaretskii
2014-09-12 15:21 ` Andreas Schwab
2014-09-12 17:15 ` Eli Zaretskii
2014-09-12 17:43 ` Andreas Schwab
2014-09-12 15:53 ` David Kastrup
2014-09-12 17:22 ` Eli Zaretskii
2014-09-12 19:28 ` David Kastrup
2014-09-12 19:59 ` Eli Zaretskii
2014-09-12 13:57 ` David Kastrup
2014-09-12 14:26 ` Eli Zaretskii
2014-09-12 11:38 ` Eric S. Raymond
2014-09-12 13:14 ` Eli Zaretskii
2014-09-12 16:27 ` Eric S. Raymond
2014-09-12 11:46 ` Harald Hanche-Olsen
2014-09-12 13:56 ` Paul Eggert
2014-09-12 15:08 ` Barry Warsaw
2014-09-12 16:16 ` Eric S. Raymond
2014-09-12 6:47 ` Thien-Thi Nguyen
2014-09-12 7:25 ` David Kastrup
2014-09-12 9:34 ` Thien-Thi Nguyen
2014-09-12 8:18 ` Eli Zaretskii
2014-09-12 8:34 ` Eric S. Raymond
2014-09-12 8:40 ` Eric S. Raymond
2014-09-12 11:47 ` Andreas Schwab
2014-09-12 11:57 ` Eric S. Raymond
2014-09-12 12:17 ` David Kastrup
2014-09-12 13:51 ` Andreas Schwab
2014-09-12 15:54 ` Eric S. Raymond
2014-09-12 16:04 ` David Kastrup
2014-09-12 16:18 ` Andreas Schwab
2014-09-12 16:28 ` Eric S. Raymond
2014-09-12 16:43 ` David Kastrup
2014-09-12 20:19 ` resolving ambiguity in action stamps (was: Everyone, please stop making my life more difficult) Joshua Judson Rosen
2014-09-12 20:41 ` Eric S. Raymond
2014-09-12 21:44 ` resolving ambiguity in action stamps Joshua Judson Rosen
2014-09-13 3:45 ` resolving ambiguity in action stamps (was: Everyone, please stop making my life more difficult) Stephen J. Turnbull
2014-09-13 5:35 ` Eric S. Raymond
2014-09-13 6:57 ` Stephen J. Turnbull
2014-09-13 7:26 ` resolving ambiguity in action stamps Harald Hanche-Olsen
2014-09-13 10:50 ` Eric S. Raymond
2014-09-13 12:43 ` Yuri Khan
2014-09-14 7:34 ` Stephen J. Turnbull
2014-09-14 10:55 ` Eric S. Raymond
2014-09-14 11:03 ` David Kastrup
2014-09-14 13:30 ` Stephen J. Turnbull
2014-09-14 14:06 ` David Kastrup
2014-09-14 15:51 ` Stephen J. Turnbull
2014-09-14 14:21 ` Eric S. Raymond
2014-09-14 15:45 ` Stephen J. Turnbull
2014-09-14 15:59 ` David Kastrup
2014-09-14 17:12 ` Eric S. Raymond [this message]
2014-09-15 0:09 ` Stephen J. Turnbull
2014-09-13 8:51 ` Andreas Schwab
2014-09-12 14:12 ` Everyone, please stop making my life more difficult Sam Steingold
2014-09-12 14:36 ` David Kastrup
2014-09-12 14:44 ` Yuri Khan
2014-09-12 15:24 ` Sam Steingold
2014-09-12 15:59 ` David Kastrup
2014-09-12 16:12 ` Eric S. Raymond
2014-09-12 17:06 ` Stefan Monnier
2014-09-12 20:35 ` Thien-Thi Nguyen
2014-09-12 15:21 ` Sam Steingold
2014-09-12 15:34 ` Harald Hanche-Olsen
2014-09-12 15:51 ` David Kastrup
2014-09-12 17:44 ` Stephen J. Turnbull
2014-09-12 17:58 ` David Caldwell
2014-09-12 19:19 ` Stephen J. Turnbull
2014-09-12 18:01 ` Harald Hanche-Olsen
2014-09-12 19:36 ` Joshua Judson Rosen
2014-10-28 21:11 ` Randal L. Schwartz
2014-09-12 15:30 ` Phillip Lord
2014-09-12 15:57 ` David Kastrup
2014-09-12 17:10 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140914171211.GA2521@thyrsus.com \
--to=esr@thyrsus.com \
--cc=emacs-devel@gnu.org \
--cc=hanche@math.ntnu.no \
--cc=stephen@xemacs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.