Bazaar references complicate the git transition

Bazaar references complicate the git transition

[Eric S. Raymond]

This is particularly a heads-up for RMS and Andreas.

I missed something on my first pass through the git mirror that I
shouldn't have.  Some commit comments have Bazaar local revision
numbers in them referring to other commits.  (It is possible
others have full hashes in them; I haven't looked closely enough at
everything yet to be sure.)

Left uncorrected, this would be bad.  Those revision numbers 
will become meaningless after the git transition. Information about
which commits refer to which others would be lost.  This would be 
particularly unfortunate with respect to reversion and correction
commits.

The good news: in reposurgeon, I have a good tool for quickly finding
and moving these to VCS-independent forms.  It's a VCS history editor
which does just about everything you could imagine such a tool
doing. It can take in RCS, CVS, Subversion, hg, bzr, and git
repositories; it can emit all of those except CVS (Subversion output
is alpha-stage).

The bad news: when reposurgeon edits a commit comment, all hashes of
its descendants are (necessarily) altered.  This means, in practice, 
that the reqired modifications cannot be done in situ on the 
Savannah repo.

Here's how the procedure will need to go:

1. Commits to bzr and git repos are temporarily closed.

2. I clone the Savannah git repo.

3. I signal for a reset of the Savannah git repo to empty.

4. I apply a pre-built reposurgeon script fixing the references.

5. I push the altered repo to the empty repo on Savannah.

6. Commits are opened again.  (The commit-mirroring from bzr
   will not care that the git repo has been altered.)

Step 4 will only take a few minutes (I'll build the modification
script ahead of time).  The problem that is the steps around that
require going through Savannah's admins, who (a) don't have procedures
for this sort of thing, and (b) are often difficult to reach and get a
response from.

That's why I think this needs an RMS intervention.

The two pain points are: (a) blocking/unblocking repo access, and
(b) resetting the repo to empty. We need a way to push those buttons,
either through a web interface or through an admin paying attention.

In the ideal case, Andreas and I would pick a date and time, then
at that time join an IRC chat with a Savannah admin who has been 
pre-briefed and knows what to do. The whole process should not take
more than 30 minutes.

Note: this needs to happen *before* the release tags are cryptosigned,
beacause of the hash invalidations.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

As the Founding Fathers knew well, a government that does not trust its honest,
law-abiding, taxpaying citizens with the means of self-defense is not itself
worthy of trust. Laws disarming honest citizens proclaim that the government
is the master, not the servant, of the people.
        -- Jeff Snyder

Re: Bazaar references complicate the git transition

[Juanma Barranquero]

On Sat, Jan 11, 2014 at 4:54 PM, Eric S. Raymond <esr@thyrsus.com> wrote:

> Some commit comments have Bazaar local revision
> numbers in them referring to other commits.  (It is possible
> others have full hashes in them; I haven't looked closely enough at
> everything yet to be sure.)
>
> Left uncorrected, this would be bad.  Those revision numbers
> will become meaningless after the git transition.

Are you planning to update also references to specific revnos in the
ChangeLogs? They will also become meaningless.

(BTW, this is going to make some people quite happy...)

     J

Re: Bazaar references complicate the git transition

[Eric S. Raymond]

Juanma Barranquero <lekktu@gmail.com>:
> Are you planning to update also references to specific revnos in the
> ChangeLogs? They will also become meaningless.
> 
> (BTW, this is going to make some people quite happy...)

That would be somewhat trickier.  But it can be done.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Bazaar references complicate the git transition

[Juanma Barranquero]

On Sat, Jan 11, 2014 at 5:29 PM, Eric S. Raymond <esr@thyrsus.com> wrote:

> That would be somewhat trickier.  But it can be done.

As a last resort, it can be done afterwards, assuming you keep a list
of (revno,git-id), but if it is done "on the fly", much better.

     J

Re: Bazaar references complicate the git transition

[David Kastrup]

esr@thyrsus.com (Eric S. Raymond) writes:

> This is particularly a heads-up for RMS and Andreas.
>
> I missed something on my first pass through the git mirror that I
> shouldn't have.  Some commit comments have Bazaar local revision
> numbers in them referring to other commits.  (It is possible
> others have full hashes in them; I haven't looked closely enough at
> everything yet to be sure.)
>
> Left uncorrected, this would be bad.  Those revision numbers 
> will become meaningless after the git transition. Information about
> which commits refer to which others would be lost.  This would be 
> particularly unfortunate with respect to reversion and correction
> commits.
>
> The good news: in reposurgeon, I have a good tool for quickly finding
> and moving these to VCS-independent forms.  It's a VCS history editor
> which does just about everything you could imagine such a tool
> doing. It can take in RCS, CVS, Subversion, hg, bzr, and git
> repositories; it can emit all of those except CVS (Subversion output
> is alpha-stage).
>
> The bad news: when reposurgeon edits a commit comment, all hashes of
> its descendants are (necessarily) altered.  This means, in practice, 
> that the reqired modifications cannot be done in situ on the 
> Savannah repo.

Would it be an option to leave the original commits unchanged but add a
"note" to it containing the git commit id?

On the other hand, rewriting the history is a one-time cost.  It will,
for a while, double the repository size for preexisting git repo users
(until the dangling references get garbage collected three or four
months later).  And it will be a nuisance for any local branches.

-- 
David Kastrup

Re: Bazaar references complicate the git transition

[Eric S. Raymond]

David Kastrup <dak@gnu.org>:
> Would it be an option to leave the original commits unchanged but add a
> "note" to it containing the git commit id?

Theoretically, yes.  Realistically, the notes facility is one of those
historical polyps hanging off the side of git that receives little
attention and less tool support.  As with the git bundle facility, I
fear becoming a victim of bitrot and would prefer not to rely on it at
all.
 
> On the other hand, rewriting the history is a one-time cost.

Yes.

> It will, for a while, double the repository size for preexisting git
> repo users (until the dangling references get garbage collected
> three or four months later).

No, I don't think you understand.  Everyone will have to reclone.
I'll repack the edited version; the clones will be drastically
*smaller*.

>And it will be a nuisance for any local branches.

Local git branches, yes.  There are easy ways around that.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Bazaar references complicate the git transition

[Juanma Barranquero]

On Sat, Jan 11, 2014 at 5:40 PM, Eric S. Raymond <esr@thyrsus.com> wrote:

> Realistically, the notes facility is one of those
> historical polyps

Git notes were introduced in 1.6.6, almost exactly three years ago.
Yours is a quite interesting definition of "historical".

     J

Re: Bazaar references complicate the git transition

[Timur Aydin]

On 01/11/14 18:40, Eric S. Raymond wrote:
> David Kastrup <dak@gnu.org>:
>> Would it be an option to leave the original commits unchanged but add a
>> "note" to it containing the git commit id?
> 
> Theoretically, yes.  Realistically, the notes facility is one of those
> historical polyps hanging off the side of git that receives little
> attention and less tool support.  As with the git bundle facility, I
> fear becoming a victim of bitrot and would prefer not to rely on it at
> all.

What about _appending_ the git hash to the commit message? That way, the
bzr revision id would still be there. That way, discussions on this
list, other mailing lists, newsgroups and the web in general where bzr
revision id's are mentioned would continue to be useful.

-- 
Timur

Re: Bazaar references complicate the git transition

[Eric S. Raymond]

Timur Aydin <ta@taydin.org>:
> What about _appending_ the git hash to the commit message? That way, the
> bzr revision id would still be there. That way, discussions on this
> list, other mailing lists, newsgroups and the web in general where bzr
> revision id's are mentioned would continue to be useful.

That still invalidates hashes.  If you're going to do that, you might
as well go ahead and change all references to action stamps.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Bazaar references complicate the git transition

[Eli Zaretskii]

> From: esr@thyrsus.com (Eric S. Raymond)
> Date: Sat, 11 Jan 2014 10:54:29 -0500 (EST)
> 
> I missed something on my first pass through the git mirror that I
> shouldn't have.  Some commit comments have Bazaar local revision
> numbers in them referring to other commits.  (It is possible
> others have full hashes in them; I haven't looked closely enough at
> everything yet to be sure.)

Which reminds me: what about the "fixes bug" field of the commit
metadata? are they copied into the git repo?  If so, how can I display
them in git?

Re: Bazaar references complicate the git transition

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> Which reminds me: what about the "fixes bug" field of the commit
> metadata? are they copied into the git repo?  If so, how can I display
> them in git?

I don't know yet.  I'll look into this.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Bazaar references complicate the git transition

[David Reitter]

Eric,

Thanks for working on the transition.

Please do not alter history in the git repository.  This would be bad for everyone downstream of the git mirror, and downright catastrophic for projects like mine (with 50+ merges of the course of years).

Why not use the mechanism that is foreseen for revising commit messages going forward?
Either "notes", as suggested, or a separate file (like the Changelog file).  If and when someone needs to resolve a reference, it could be easily done manually or automatically.

- David  (of aquamacs.org)


On Jan 11, 2014, at 10:54 AM, Eric S. Raymond <esr@thyrsus.com> wrote:

> This is particularly a heads-up for RMS and Andreas.
> 
> I missed something on my first pass through the git mirror that I
> shouldn't have.  Some commit comments have Bazaar local revision
> numbers in them referring to other commits.  (It is possible
> others have full hashes in them; I haven't looked closely enough at
> everything yet to be sure.)
> 
> Left uncorrected, this would be bad.  Those revision numbers 
> will become meaningless after the git transition. Information about
> which commits refer to which others would be lost.  This would be 
> particularly unfortunate with respect to reversion and correction
> commits.
> 
> The good news: in reposurgeon, I have a good tool for quickly finding
> and moving these to VCS-independent forms.  It's a VCS history editor
> which does just about everything you could imagine such a tool
> doing. It can take in RCS, CVS, Subversion, hg, bzr, and git
> repositories; it can emit all of those except CVS (Subversion output
> is alpha-stage).
> 
> The bad news: when reposurgeon edits a commit comment, all hashes of
> its descendants are (necessarily) altered.  This means, in practice, 
> that the reqired modifications cannot be done in situ on the 
> Savannah repo.
> 
> Here's how the procedure will need to go:
> 
> 1. Commits to bzr and git repos are temporarily closed.
> 
> 2. I clone the Savannah git repo.
> 
> 3. I signal for a reset of the Savannah git repo to empty.
> 
> 4. I apply a pre-built reposurgeon script fixing the references.
> 
> 5. I push the altered repo to the empty repo on Savannah.
> 
> 6. Commits are opened again.  (The commit-mirroring from bzr
>   will not care that the git repo has been altered.)
> 
> Step 4 will only take a few minutes (I'll build the modification
> script ahead of time).  The problem that is the steps around that
> require going through Savannah's admins, who (a) don't have procedures
> for this sort of thing, and (b) are often difficult to reach and get a
> response from.
> 
> That's why I think this needs an RMS intervention.
> 
> The two pain points are: (a) blocking/unblocking repo access, and
> (b) resetting the repo to empty. We need a way to push those buttons,
> either through a web interface or through an admin paying attention.
> 
> In the ideal case, Andreas and I would pick a date and time, then
> at that time join an IRC chat with a Savannah admin who has been 
> pre-briefed and knows what to do. The whole process should not take
> more than 30 minutes.
> 
> Note: this needs to happen *before* the release tags are cryptosigned,
> beacause of the hash invalidations.
> -- 
> 		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
> 
> As the Founding Fathers knew well, a government that does not trust its honest,
> law-abiding, taxpaying citizens with the means of self-defense is not itself
> worthy of trust. Laws disarming honest citizens proclaim that the government
> is the master, not the servant, of the people.
>        -- Jeff Snyder
> 

Re: Bazaar references complicate the git transition

[Eric S. Raymond]

David Reitter <david.reitter@gmail.com>:
> Please do not alter history in the git repository.  This would be
> bad for everyone downstream of the git mirror, and downright
> catastrophic for projects like mine (with 50+ merges of the course
> of years).

I think I can work with you to prevent a catastrophe.  I've faced this
kind of situation before, and I've built the best tools in existence 
for coping with it.

> Why not use the mechanism that is foreseen for revising commit
> messages going forward?  Either "notes", as suggested, or a separate
> file (like the Changelog file).  If and when someone needs to
> resolve a reference, it could be easily done manually or
> automatically.

I know from lots of previous experience with messy conversions (NUT,
Hercules, Roundup, groff, and a number of others) that these sorts of
halfway-out-of-band mechanisms are fragile and *never* work as well as
advertised.  The pain you think you are avoiding with them will come 
back redoubled.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Bazaar references complicate the git transition

[David Kastrup]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> David Reitter <david.reitter@gmail.com>:
>> Please do not alter history in the git repository.  This would be
>> bad for everyone downstream of the git mirror, and downright
>> catastrophic for projects like mine (with 50+ merges of the course
>> of years).
>
> I think I can work with you to prevent a catastrophe.  I've faced this
> kind of situation before, and I've built the best tools in existence 
> for coping with it.
>
>> Why not use the mechanism that is foreseen for revising commit
>> messages going forward?  Either "notes", as suggested, or a separate
>> file (like the Changelog file).  If and when someone needs to
>> resolve a reference, it could be easily done manually or
>> automatically.
>
> I know from lots of previous experience with messy conversions (NUT,
> Hercules, Roundup, groff, and a number of others) that these sorts of
> halfway-out-of-band mechanisms are fragile and *never* work as well as
> advertised.  The pain you think you are avoiding with them will come 
> back redoubled.

Actually, a plain text file mapping bazar revision numbers to git commit
ids will work exactly as well as advertised.

sed -n 's/^4535 //p' BZR-REVISIONS

will do what is expected and can be utilized in scripts or whatever.

-- 
David Kastrup

Re: Bazaar references complicate the git transition

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Actually, a plain text file mapping bazar revision numbers to git commit
> ids will work exactly as well as advertised.

Every git commit has a note that contains the origin bzr revid.  From
that a script can generate revison numbers, but note that the numbers
are dependent on the branch where the revids are looked up.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Bazaar references complicate the git transition

[Eli Zaretskii]

> Date: Sat, 11 Jan 2014 12:27:00 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: Emacs-Devel devel <emacs-devel@gnu.org>
> 
> I know from lots of previous experience with messy conversions (NUT,
> Hercules, Roundup, groff, and a number of others) that these sorts of
> halfway-out-of-band mechanisms are fragile and *never* work as well as
> advertised.  The pain you think you are avoiding with them will come 
> back redoubled.

"bzr log" suggests that there are only about 120 commits that
reference other revisions.  Perhaps this isn't worth the trouble?  Any
forensics in the future can find the referenced revision, if it needs
to, given some small effort.

Re: Bazaar references complicate the git transition

[Eli Zaretskii]

> Date: Sat, 11 Jan 2014 20:04:41 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: david.reitter@gmail.com, emacs-devel@gnu.org
> 
> "bzr log" suggests that there are only about 120 commits that
> reference other revisions.

Sorry, make that 160 (still very few).

Re: Bazaar references complicate the git transition

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> "bzr log" suggests that there are only about 120 commits that
>> reference other revisions.
>
> Sorry, make that 160 (still very few).

Revision numbers in bug reports and mailing list messages also counts.

IMHO a file mapping bzr revnos to git SHAs is TRT.

Re: Bazaar references complicate the git transition

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 1598 bytes --]

() Óscar Fuentes <ofv@wanadoo.es>
() Sat, 11 Jan 2014 19:24:42 +0100

   Revision numbers in bug reports and mailing list messages also counts.

   IMHO a file mapping bzr revnos to git SHAs is TRT.

Right.  Operating only on the repo externalizes the "problem", but does
not eliminate it (and in fact sows confusion).  In any case, i think
this is a good opportunity (in the sense of "better sooner than later")
to switch to a VCS-neutral reference scheme for new ChangeLog entries.

I've suggested "DATE, TITLE" before, as that's what i use personally[0],
but i think that won't fly w/ Emacs unless TITLE becomes mandatory.

In hopes of "attacking the problem from above", i tried unsuccessfully
to get TITLE mandatory in the GNU Coding Standards, some years back.
Upon reflection (of the words of the discussion's other participants,
mostly :-D), i've come to accept that such conventions are best decided
at the individual project level, by its maintainers.

So, now i suggest the Emacs maintainers mandate TITLE in the ChangeLog,
and only pending that, the adoption of "DATE, TITLE" as a VCS-neutral
reference.  Otherwise, things can only grow hairier w/ time.


_________________________
[0] E.g., see <http://www.gnuvola.org/software/> and choose any tarball.
    In some of the HACKING files, there is even more related verbiage!


-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Bazaar references complicate the git transition

[Eli Zaretskii]

> From: Thien-Thi Nguyen <ttn@gnu.org>
> Date: Sat, 11 Jan 2014 20:15:24 +0100
> 
> So, now i suggest the Emacs maintainers mandate TITLE in the ChangeLog,
> and only pending that, the adoption of "DATE, TITLE" as a VCS-neutral
> reference.  Otherwise, things can only grow hairier w/ time.

We could try, but I don't expect it to fly: people seldom adhere to
practices that don't really help them in the short run.

Re: Bazaar references complicate the git transition

[Paul Eggert]

Óscar Fuentes wrote:
> IMHO a file mapping bzr revnos to git SHAs is TRT.

+1.  It would simplify the transition hassle,
and would address the problem for the (few)
future people doing software archeology better
than attempting to rewrite history now.

Re: Bazaar references complicate the git transition

[Eric S. Raymond]

Paul Eggert <eggert@cs.ucla.edu>:
> Óscar Fuentes wrote:
> >IMHO a file mapping bzr revnos to git SHAs is TRT.
> 
> +1.  It would simplify the transition hassle,
> and would address the problem for the (few)
> future people doing software archeology better
> than attempting to rewrite history now.

I'm going to have to generate such a file anyway, whether or not the history
is edited. It would be input for the edit procedore
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Bazaar references complicate the git transition

[David Reitter]

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


On Jan 11, 2014, at 1:08 PM, Eli Zaretskii <eliz@gnu.org> wrote:

>> Date: Sat, 11 Jan 2014 20:04:41 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: david.reitter@gmail.com, emacs-devel@gnu.org
>> 
>> "bzr log" suggests that there are only about 120 commits that
>> reference other revisions.
> 
> Sorry, make that 160 (still very few).

Re: Bazaar references complicate the git transition

[David Kastrup]

David Reitter <david.reitter@gmail.com> writes:

> 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.

Aaaaaaand we have a winner.

The only downside is that a list of all current tags will be, uhm,
unpretty.  But it is so already.  And when tagging only every
_referenced_ version, this should not be too bad.

-- 
David Kastrup

Re: Bazaar references complicate the git transition

[Eric S. Raymond]

David Reitter <david.reitter@gmail.com>:
> 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.  But here are some longer-scale problems with it:

1. Tags are much more fragile than IDs in commit comments.  They could
easily get deleted by someone's typo or moment of inattention.

2. What happens when people have forgotten the syntax of a Bazaar
revision ID?  It's just a bare decimal integer, after all. 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:20!esr@thyrsus.com

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.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Bazaar references complicate the git transition

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 1825 bytes --]

On Jan 11, 2014, at 4:26 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> 
> What you're suggesting seems to me like the best medium-timescale choice
> anyone has offered.  But here are some longer-scale problems with it:
> 
> 1. Tags are much more fragile than IDs in commit comments.  They could
> easily get deleted by someone's typo or moment of inattention.

It's an asymmetry shared with references to bug IDs, URLs (debbugs...), or e-mail addresses of committer names.

If tags get lost, someone can easily push them again.  It's a d-VCS after all.

> 2. What happens when people have forgotten the syntax of a Bazaar
> revision ID?  It's just a bare decimal integer, after all. Suppose a
> future VCS also uses commit IDs in this form?

If we're not automatically converting anything, future readers of a commit message, if they happen to come across the evidently rare reference to a bzr revid, will have to parse it and translate to the "bzr/#" git tag.

Mistakes happen, including inadequate commit messages, or simply bugs in the commits.
DVCSs fossilize the errors, in code and text alike.  That's okay!

> My practice for the last several conversions I've done has been to change
> all native revision IDs inline to these timestamp!committer pairs.

As you know, git is conceived around the notion of globally unique hashes to refer to a commit and the state of the history at the time.  It's one of the elegant ideas behind git that make it work so well.  Please do not rewrite history.

I had to stitch together two repositories when switching from one Emacs git mirror to the official one.  My repository still carries both conversions, and I don't see a way to get rid of them (without breaking hashes, and probably not at all unless git can migrate merges with lots of conflicts).

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

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

[Joshua Judson Rosen]

"Eric S. Raymond" <esr@thyrsus.com> writes:
>
> David Reitter <david.reitter@gmail.com>:
> > 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:20!esr@thyrsus.com
>
> 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."

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

[Eric S. Raymond]

Joshua Judson Rosen <rozzin@geekspace.com>:
> (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)

Of course.  I've done this before. ;-)
 
> 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.

I know. That's why the *full* form of an action stamp is actually

  {ISO-date }!{email-address}#{sequence-nummber}

I have needed that generality on some Subversion repositories.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

[Joshua Judson Rosen]

"Eric S. Raymond" <esr@thyrsus.com> writes:
>
> Joshua Judson Rosen <rozzin@geekspace.com>:
> >
> > 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.
>
> I know. That's why the *full* form of an action stamp is actually
>
>   {ISO-date }!{email-address}#{sequence-nummber}

Ah, OK--I see that in the reposurgeon manual, now.

I was looking for something like that in your "RFC: Action stamps" post
<http://esr.ibiblio.org/?p=3872> and couldn't find it there.

Is the reposurgeon manual the authoritative document on action stamps?
Or is there another doc with more information? (`more information'
being, e.g., the points in various comments attached to
<http://esr.ibiblio.org/?p=4854>)

(all of this is only really relevant to the matter at hand _if_ there
 are collisions, of course)

> I have needed that generality on some Subversion repositories.

Hunh. It's much less obvious to me why that would happen in svn.

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

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

[Eric S. Raymond]

Joshua Judson Rosen <rozzin@geekspace.com>:
> Is the reposurgeon manual the authoritative document on action stamps?

Yes.  I haven't written the RFC yet. :-)
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Bazaar references complicate the git transition

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I'm willing to talk with the Savannah people to ask them to cooperate
with this, if Stefan approves this particular procedure as what to do.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Bazaar references complicate the git transition

[Stefan Monnier]

> I'm willing to talk with the Savannah people to ask them to cooperate
> with this, if Stefan approves this particular procedure as what to do.

I don't know what procedure you're talking about.


        Stefan

Re: Bazaar references complicate the git transition

[Eric S. Raymond]

Stefan Monnier <monnier@iro.umontreal.ca>:
> > I'm willing to talk with the Savannah people to ask them to cooperate
> > with this, if Stefan approves this particular procedure as what to do.
> 
> I don't know what procedure you're talking about.

Temporarily disable commits, zero the Savannah repo while I fix up the 
Bazaar references, reload the Savannah repo from the fixed-up version.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Bazaar references complicate the git transition

[Stefan Monnier]

> Temporarily disable commits, zero the Savannah repo while I fix up the 
> Bazaar references, reload the Savannah repo from the fixed-up version.

If you're talking about the Git repository, yes, we'll probably want to
overwrite the current one with some new one.

But the repository has denynonfastforwards=false, so we should be able
to overwrite without any further configuration.  When the Git repository
becomes *The* repository, we'll want to ask the Savannah guys to set
denynonfastforwards=true.


        Stefan

Re: Bazaar references complicate the git transition

[Eric S. Raymond]

Stefan Monnier <monnier@iro.umontreal.ca>:
> > Temporarily disable commits, zero the Savannah repo while I fix up the 
> > Bazaar references, reload the Savannah repo from the fixed-up version.
> 
> If you're talking about the Git repository, yes, we'll probably want to
> overwrite the current one with some new one.

OK.  I know pne thing that needs to be done, which is reference lifting.
What else do you have in mind that will require the overwrite.

> But the repository has denynonfastforwards=false, so we should be able
> to overwrite without any further configuration.  When the Git repository
> becomes *The* repository, we'll want to ask the Savannah guys to set
> denynonfastforwards=true.

Iiinterresting. I've never tried that.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Bazaar references complicate the git transition

[Glenn Morris]

Stefan Monnier wrote:

> When the Git repository becomes *The* repository, we'll want to ask
> the Savannah guys to set denynonfastforwards=true.

So we lose the ability to control that ourselves, like we could with
`bzr config'?

Re: Bazaar references complicate the git transition

[Stefan Monnier]

>> When the Git repository becomes *The* repository, we'll want to ask
>> the Savannah guys to set denynonfastforwards=true.
> So we lose the ability to control that ourselves, like we could with
> `bzr config'?

I don't know, I haven't tried to play with "git config" yet.


        Stefan

Re: Bazaar references complicate the git transition

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    > I'm willing to talk with the Savannah people to ask them to cooperate
    > with this, if Stefan approves this particular procedure as what to do.

    I don't know what procedure you're talking about.

ESR asked me to intervene with Savannah people for cooperation
in part of his proposed scheme for moving to git.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.