QUERY: commit: Merge.
Michael Sperber
sperber at deinprogramm.de
Thu Dec 20 10:51:37 EST 2007
"Vin Shelton" <acs at alumni.princeton.edu> writes:
> On Dec 20, 2007 5:35 AM, Stephen Turnbull
> <unwelcome-guest at alioth.debian.org> wrote:
>> changeset: 4341:5938003821ac8b2fbb12f38379fdcfb115cf79a9
>> tag: tip
>> parent: 4340:2834fcbd1a92d5007166f938e9d0959010f3c12f
>> parent: 4339:89954a8cc73d4c1ad96065fc9d0ae5866f021127
>> user: Stephen J. Turnbull <stephen at xemacs.org>
>> date: Thu Dec 20 02:34:02 2007 -0800
>> files:
>> description:
>> Merge.
>
> Stephen - what is this message? Is this a merge to your private
> workspace?
It's the merge between the changes Stephen made, and the other changes
made since the revision Stephen started form. CVS couldn't express
this, since you could only apply to the head revision, but with
Mercurial, it's different. Normally, it's nothing to worry about.
> On a separate (but perhaps related) topic, Michael - how do you
> propose to track when you (or I or anyone) promote changesets from the
> hg xemacs repository to the hg xemacs-beta repository? Ideally a
> follow-up message to the original PATCH/COMMIT message similar to what
> I send for 21.4 patches should be sent, but if sending a non-followup
> message is easier to automate, then lets do that. Either way, there
> needs to be some message sent to XEmacs-patches for each commit to the
> hg xemacs-beta repository.
My strategy is to pull everything that's at least 48 hours old and
hasn't been objected to, and only if I can build and start once that
state. It's mostly a safeguard to prevent badly breaking the build for
xemacs-beta users. I don't think cherry-picking is necessary at this
point---that would be a lot more work.
It'll be easier to track once we can bake the Mercurial changeset id
into xemacs_extra_name. I'm working on it, but having trouble breaking
into Windows.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
More information about the XEmacs-Patches
mailing list