Re: Sharing the savannah hg archive (was: Re: Savannah server unreliable?)

[John W. Eaton]

On 11-Sep-2008, Jaroslav Hajek wrote:

| Well, that's not the same. I want to get:
| 
| current patch log entry
| 
| previous entries
| 
| and preserve the date.

OK, that is better, as the change is not buried.  But then it seems
odd to me that the dates are not reverse chronological (that's what I
expect to find in a ChangeLog file).

| > and the date is wrong (should be todays date for my log.  So I still
| > have to go find the log entry for the current patch and move it to the
| > top and change the date.  Then I need something like
| >
| >  hg qrefresh --currentdate
| >
| > so that in my archive, the data corresponding to the changeset matches
| > the date that the changeset was actually applied.  I'm using
| > Mercurial Queues to apply patches so that I can cleanly fix up
| > problems like this before committing; there may be other ways to do
| > it, but this is what works for me.
| >
| > If I were just synchronizing my archive with someone elses, I would
| > not do this.  But I think the situation is different when
| > cherrypicking patches.  The point is that if I look at your archive at
| > two points in time, I would not expect to find older entries suddenly
| > appearing in it later on.
| >
| 
| Why? In my opinion, it is more useful for the ChangeLog entry to
| record the date when the patch was actually created and not change
| subsequently as changesets are being moved around. When I transplant
| an older patch into the release branch, the ChangeLog tells me that
| this is some old stuff transplanted, which is useful.
| If I want to know when a particular ChangeLog entry has been added
| (i.e. when the transplant actually happened), I can ask Mercurial
| using hg annotate or something similar.

I think both dates can be useful.  Certainly they are if the patch is
in response to a bug report and you only have the date to go by to
find the report in the list archives.  Then the way I'm doing things,
this information is not as useful as it could be (espeically if the
patch is applied much later than the date it was created).  But the
fix for that problem is probably to be using a bug database and keep
track of bug report numbers.

You are keeping both dates, which is good, but they are in separate
locations.  When someone gets a copy of the distribution as a tar
file, the don't have your mercurial archive.  Should it be a
requirement that we have

Also, thinking about the distribution tar file case, the top of the
current src/ChangeLog in the release-3-0-x archive has

  2008-05-20  Kim Hansen  <address@hidden>

          * load-path.cc (load_path::do_initialize):
          Include separator when appending sys_path.

and I know that 3.0.2 was released after 2008-05-20, so I would assume
that this change is in that release also, but it is not.  So there is
a potential source of confusion.

| FWIW, I think it would not be hard to write an awk script that queries
| hg annotate and updates the date of each entry to the date when it
| appeared in the current archive.

OK, we could probably do that, but is the date that a changeset is
added to an archive always updated?  It doesn't seem to be with my
way of working with MQ unless I force the date to be refreshed.

Also, this would require an extra step every time a patch is
transplanted or merged.  Maybe it is what we should do, but it would
be nice to not have these problems.

It seems to me that if we don't care about having detailed change
history in tar file distributions, then we could just drop ChangeLog
files and keep the information in the mercurial archive.  In that
case, the problem of ChangeLog dates and the order of ChangeLog
entries goes away.  So I guess I'm wondering whether ChangeLog files
are obsolete.

jwe