[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Repo cpnversion progress report

From: Eric S. Raymond
Subject: Re: Repo cpnversion progress report
Date: Fri, 31 Jan 2014 16:07:18 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

Paul Eggert <address@hidden>:
> Eric S. Raymond wrote:
> >I hear the argument about forensics, but the Bazaar revision numbers
> >are no more helpful for that than the action stamps.
> As someone who regularly spelunks back decades, I'd prefer keeping
> these stamps as small as possible.  Even
> "2003-07-05T12:41:address@hidden" will
> cause hassles, and I especially wouldn't want to read and digest
> monsters along the lines of what someone else proposed, e.g.,
> "1985-04-18T00:49:address@hidden (bzr 1) (CVS (RCS
> 1.71) (emacs-backup ~107~)".  It doesn't scale for a revision string
> to contain all the names that the revision has ever had, for all the
> version-control systems we've ever used.

Yeah, exactly.  That's the telling argument for a single VCS-independent
action stamp, right there.  And props to you for taking the (correctly)
long view of the matter!

I'm not real happy about the action stamps being so long as it is.
Unfortunately, they're the shortest thing I've managed to come up with
that has the required properties of being unique and self-describing.

> PS.  In that 1985 example, the email address address@hidden is
> ahistorical, as Red Hat didn't exist in 1985.  That info is taken
> straight from the current bzr repository.  Most likely the
> repository was made ahistorical during an earlier conversion,
> unfortunately.

Yes, and that sort of ahistoricity was unavoidable for the simple
reason that DVCSes need email addresses as Internet-global
credentials.  The act of mapping CVS usernames to these therefore
almost necessarily introduces anachronisms.

Repository translation is *difficult*.  At least, doing a non-half-assed 
job of it is.  The tradeoffs between usability and historicity don't
have easy or pat answers.

It's especially difficult for a project as steeped in history - nay,
positively encrusted with it - as Emacs.  This is already the hairiest
conversion I've ever done, measured by complexity of the lift file,
and it's going to get much worse before it's done.  I don't expect to
ever see a messier one.
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]