Re: Converting bzr revision-IDs to action stamps (was: Bazaar references complicate the git transition)

[Joshua Judson Rosen]

"Eric S. Raymond" <address@hidden> writes:
>
> David Reitter <address@hidden>:
> > Eric,
> > 
> > Here's an idea - why don't you just tag each referenced revision in git 
> > with the bzr revision id, e.g.,
> > 
> > git tag 'bzr/115967'  de7d9800
> > 
> > That would make it trivial and seamless to find a reference later on.  
> > I would update the change log files to use the same bzr/ prefix.  
> > 
> > You can do this after the transition is done, and if people don't like it, 
> > they can undo it in the future.
> > 
> > - David
>
> That's certainly a much, much better idea than git notes or a textfile not
> tied into the VCS at all.
>
> In doing these conversions, though, I've become use to thinking like
> an archivist concerned with very long timescales. I find myself asking
> questions like this: how is the translation choice I make in *this*
> VCS conversion going to affect the *next* one, the one we don't
> foresee?  I don't want to be the person that the next guy to do a
> repository lift curses for shortsightedness. 
>
> What you're suggesting seems to me like the best medium-timescale choice
> anyone has offered.

It's somewhat similar, at least in spirit, to what bzr does when
converting from svn: all of the svn revisions effectively get additional
"svn:..."  revision-identifiers attached to them; then the bzr-svn
plugin allows looking revisions up by their svn revnums, e.g.:
"bzr diff -c svn:23". I've used that (on other projects that went
throught an svn phase), and found it quite nice to have on a number
of occasions.

Are tags the only/best provision in git for attaching that data?

> 2. What happens when people have forgotten the syntax of a Bazaar
> revision ID?  It's just a bare decimal integer, after all.

Unless there's a very specific context to this statement (e.g.: bzr
revision-IDs speficially as used in emacs trunk's commit messages),
"just a bare decimal integer" isn't necessarily accurate....

(I did notice that you wrote "It is possible others have full hashes in
them; I haven't looked closely enough at everything yet to be sure.";
take this as a `heads up' about other closely-related things to look for
as you're doing that scan)

It's also possible that someone may have written in dotted
`<revno>.<branchno>.<revno>' notation as well; *and* it may also be
harder than you think to uniquely identify bzr revisions by anything
other than their full bzr revids (what I think you're referring to as
"hashes", though they're not) or whatever other scheme the active VCS
uses to uniquely identify revisions; see below:

> Suppose a future VCS also uses commit IDs in this form?
>
> Thinking about scenarios like this is why I invented action stamps.
> This is an action stamp:
>
>      2014-01-11T16:22:address@hidden
>
> My practice for the last several conversions I've done has been to change
> all native revision IDs inline to these timestamp!committer pairs. I think
> this has good robustness properties.

It may or may not be true specifically in the case of the mainline emacs
revision history; someone will probably need/want to check (if nobody
has yet), because it's certainly _possible_ to have situations in bzr
where `timestamp!committer' works as a sort of hash bucket but _isn't_
specific enough to identify a single unique revision-object.

One of the things that I've seen (and done) on some other projects using
bzr is, for example, to replay some misplaced feature-fix commits from
trunk onto the relevant feature- or release-branch that would later be
merged back into trunk. This sort of thing results in multiple commits
in a single DAG that have the same timestamp and author (and possibly
even the same committer, if the developer doing the replay was the same
as did the original commit), but different revision-IDs (because there
are separate revision-objects attached at different points in the
graph).

-- 
"'tis an ill wind that blows no minds."