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

[Jaroslav Hajek]

On Thu, Sep 11, 2008 at 4:15 PM, John W. Eaton <address@hidden> wrote:
> On 11-Sep-2008, Jaroslav Hajek wrote:
>
> | On Wed, Sep 10, 2008 at 4:26 PM, John W. Eaton <address@hidden> wrote:
> | >
> | > The savannah site also allows pushing via ssh if you are a member of
> | > the Octave project on Savannah (that part of the hg setup on savannah
> | > seems to be more reliable, and was working for me even when the public
> | > http access was not).  Perhaps it is time to allow multiple users to
> | > push to the public archive on savannah?  That would maybe streamline
> | > the installation of patches?  However, if we do this, I think we need
> | > some ground rules about who can push without approval, how ChangeLog
> | > entries should be handled (or even whether we should continue to use
> | > them), etc.
> | >
> | > Comments?
> | >
> | > jwe
> | >
> |
> | A small note regarding ChangeLogs:
> | I now use a patched copy of Mercurial, that recognizes an option
> | `changelogmask =' in the [diff] section. When a file that matches this
> | glob mask is being diffed, and the new revision exactly matches the
> | old one plus some prepended lines (by far the most common case with
> | ChangeLogs), only the prepended lines are dumped (i.e. a contextless
> | diff). This makes much more changesets to apply smoothly when
> | transplanting or exporting/importing. If anyone is interested, I can
> | share the patch.
>
> Whatever is doing the merge in my Mercurial version now also does
> something similar (I think, if I understand your description).  But it
> is still not what I want.  Suppose I'm applying a patch to my archive
> today, but the ChangeLog has an older date, and some additional
> entries have been added above the location where the context matches.
> then I get:
>
>  newer log entries
>
>  current patch log entry
>
>  older log entries
>

Well, that's not the same. I want to get:

current patch log entry

previous entries

and preserve the date.

> 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.
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.



> jwe
>



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