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

[Jaroslav Hajek]

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.

> 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