emacs-devel
[Top][All Lists]
Advanced

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

Re: Repo cpnversion progress report


From: Eli Zaretskii
Subject: Re: Repo cpnversion progress report
Date: Fri, 31 Jan 2014 09:50:35 +0200

> Date: Thu, 30 Jan 2014 16:42:01 -0500
> From: "Eric S. Raymond" <address@hidden>
> Cc: address@hidden
> 
> Eli Zaretskii <address@hidden>:
> > The list of bzr revisions in changecomment lines is still too short,
> > about one third of the real list.
> 
> I went through the putput of bzr log --levels 0 with grep and eyeball
> last night; those are what I found.

What grep command did you use?  The regexp(s) you gave to grep are the
key.

I use "bzr log" with multiple --match-message options (they accept
Python regexps), which is similar.  So the difference must come from
the regular expressions used.

> It would be helpful if you were to supply what you think of as the
> real list.

I'm sorry, but my motivation to help you at this point is nil, I'm
sure you understand why.  I even needed to debate whether to point out
that you had a very incomplete list of references.

> > Also, it looks like you are going to _replace_ the revision numbers
> > with the time stamp, not just _add_ the time stamp?  If so, I strongly
> > suggest to leave the revision numbers intact, so that we don't lose
> > information.
> 
> After we change over, the Bazaar revision numbers will be meaningless
> except as keys to a map file which is just going to associate them
> with the action stamps I'm replacing them with.

They are not meaningless, since, as you correctly recommend, the bzr
repo should be kept frozen at the point of the switch, rather than
deleted.  If something goes wrong during the conversion, and someone
needs to do some archeology later, these numbers might help.

So I suggest to make the replacements like this:

 "rev 102609" => "2010-12-08T08:09:address@hidden (bzr r102609)"
                                                           ^^^^^^^^^^^^^
> > > # Remove every .cvsignore not older than when .gitignores were
> > > # first added.  Then rename all remaining (older) .cvsignores to
> > > # corresponding .gitignore paths; the syntax is upward-compatible.
> > > # The date marks the introduction of .gitignore files.
> > 
> > This looks gratuitous and loses information.  I think you shouldn't be
> > doing that.
> 
> What would you do instead?  What information do you believe the newer
> .cvsignores carry that the .bzrignores and .gitignores do not?

I see no need to remove files that existed at a certain date, as that
changes history for no good reason.  We have no idea whether
.gitignores and .bzrignores were indeed 100% equivalent to .cvsignores
(it's humans who did that job, and they are prone to errors).

I certainly see no reason for this part:

  Then rename all remaining (older) .cvsignores to corresponding
  .gitignore paths; the syntax is upward-compatible.

This doesn't make sense at all to me: would you also rename a .c file
to a .el file if it was at some later point rewritten in Lisp?  If I
checkout a revision from 1990, I don't want to see a .gitignore file
that didn't exist, and I certainly _do_ want to see a .cvsignore that
did.

The .*ignore files are here to make the display of status command
cleaner, that's all.  When I checkout an old revision, I don't need
that feature, because I'm not going to commit from that point.

So I don't see what is the motivation for this history rewrite in the
first place.  What do we gain from that?



reply via email to

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