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

[Jaroslav Hajek]

On Thu, Sep 11, 2008 at 7:55 PM, Jaroslav Hajek <address@hidden> wrote:
> On Thu, Sep 11, 2008 at 6:27 PM, John W. Eaton <address@hidden> wrote:
>> 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.
>>
>
> I reckon it is all about what you expect to be in the ChangeLog file.
> My reasoning for leaving the dates intact is that I read the above
> entry as:
> "On May 20 2008, Kim Hansen contributed the following changes..."
> Then, it seems weird to update the date to September, because Kim has
> contributed nothing in Semptember (OK maybe he has, but not this
> patch). To stretch it ad absurdum, Kim may have already died, and yet
> have a ChangeLog entry with a post mortem date (my apologies, Kim, if
> you read this).
> To put it another way, it seems to me that if I am to update the date,
> I can just as well update the author.
>
>> | 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.
>>
>
> I think it updates the date when transplanting. Not sure about mq.
> Perhaps it can be configured in some way, or is it a bug? I reckon
> that when you commit a mq-managed changeset (using hg rm), its date
> should be updated.
>

Okay, it seems I was wrong. The date of the original changeset is also
preserved. After all, it's little wonder since if it was the other way
around, then Mercurial should maybe update the dates also when pulling
or cloning. In other words, it seems Mercurial treats the changeset
dates in the same way I treat dates in ChangeLog entries - they're
just an immutable part of the patch.

>>
>> 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.
>>
>
> That's not exactly what I meant. I was thinking about running such
> script when making a release (in make dist, probably). In the
> development sources, we would keep just the original dates (patch
> creation), as mercurial is keeping the dates of patch application for
> us (but perhaps not always correctly, as you note above).
> The distributed tarballs lack this information, so we could supply
> them with automatically generated, extended ChangeLogs in the form
>
> 2008-05-20  Kim Hansen  <address@hidden>   (Applied 2008-09-11)
>
> or vice versa
>
> 2008-09-11  Kim Hansen  <address@hidden>   (Originally 2008-05-20)
>
>
>> 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.
>>
>
> If we can somehow store something similar to ChangeLogs as some
> additional info that gets trasferred along with changesets, then
> probably it's the best way forward. I don't know how to do that,
> though. It seems to me that the only additional information available
> is the commit message.
>
>
>> jwe
>>
>
>
>
> --
> RNDr. Jaroslav Hajek
> computing expert
> Aeronautical Research and Test Institute (VZLU)
> Prague, Czech Republic
> url: www.highegg.matfyz.cz
>



-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz