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

[Jaroslav Hajek]

On Fri, Sep 12, 2008 at 7:20 AM, Jaroslav Hajek <address@hidden> wrote:
> On Thu, Sep 11, 2008 at 10:27 PM, John W. Eaton <address@hidden> wrote:
>> On 11-Sep-2008, Jaroslav Hajek wrote:
>>
>> | On Thu, Sep 11, 2008 at 7:55 PM, Jaroslav Hajek <address@hidden> wrote:
>> |
>> | > 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.
>>
>> Are both dates available in the mercurial archive?  Where do they
>> appear?  A simple "hg log" for the release-3-0-x archive shows:
>>
>>  changeset:   7574:d92e612d5fe3
>>  tag:         tip
>>  user:        Kim Hansen
>>  date:        Tue May 20 16:49:02 2008 -0400
>>  summary:     load-path.cc (load_path::initialize): include separator when 
>> appending sys_path
>>
>> for example.  It seems to me that it might be helpful to have both
>> dates, at least when cherrypicking changes from another archive.
>>
>
> It does not seem so. Apparently the date is taken from the changeset header.
> I don't think there's an option for transplant to update the date, but
> I can certainly try to add it, as that seems useful to me.

Okay, that was fairly straightforward. I've sent the patch to
Mercurial ML. So, if you think it's more sound, I can start
transplanting changesets using the -D option (like qrefresh has).

>
>> But anyway, what about the idea of simply dropping the formal
>> ChangeLog?  Or perhaps only auto-generating them from the Mercurial
>> commit logs when we make releases?
>>
>
> I'm not against it. They helped me a few times, but I guess we can do
> without them. The disadvantage of using just Mercurial commit logs is
> that they contain only one global message for all of the changes. But
> I'm OK with that, it will even make writing patches easier.
> To put it simply, the managed source files are not a good place for
> anything that should change dynamically when changesets are being
> manipulated.
> We can still be happy with "my way" of using changelog dates, or not
> use dates in changelog entries, or drop the changelogs. The last
> option has the advantage that it will make changesets apply smoothly
> without patching mercurial, so perhaps it is the best after all.
>
>> 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