Re: Commit (JMM-DOUBLEGRAPHICS-1): merge from head 1/2

From: Mark Gilbert <>
Date: Wed Dec 29 2004 - 19:37:28 CET

On Wed, 2004-12-29 at 13:12 -0500, Hubert Figuiere wrote:
> On Wed, 2004-12-29 at 12:55 -0500, Mark Gilbert wrote:
> > On Wed, 2004-12-29 at 12:45 -0500, Hubert Figuiere wrote:
> > > On Sat, 2004-12-25 at 00:53 +0100, J.M. Maurer wrote:
> > > > MG: could you check if i didn't screw anything up while fixing the merge
> > > > errors, before i 'fix' more? Don't know if I should have tagging
> > > > something or not ...
> > >
> > >
> > > Since I never got any reply from the dude who branched (MG for that
> >
> > Actually, you did, and you even sent a followup in response, with no new
> > questions.
> Because you did not answer the previous one. The question where clear:
> What is the tag for the branchpoint?

I answered this, and in great detail. I still have the message if you
need me to resend it. To summarize for the curious and chuckling
onlookers, there is none, because you've yet to show a need for it. If
for some strange reason you need to get the difference on HEAD (which
would be huge) between when it was branched and now, there are several
different ways to do this, including undoing the interbranch diff on the
branch, and very simply you can just use the date (it hasn't changed, I
assure you, short of some excercise in time travel proposed by martin
(-: )
If you can demonstrate a need for one, I can create one. One can be
created at any point between now and eternity, because the date of the
branch has not changed and never will (to preclude any philosophical
discussion on the space-time continuum).

> What is the "lastmerge" tag ?
> What is jmm_doublegraphics_1_priorsync ?

You did not ask me these questions, you asked uwog, on irc, last month,
and he explained it, and after that you just said that you mailed me,
but these questions were not in the three that you asked, and because
uwog had explained it, I saw no need to answer a question that hadn't
been asked. Although technically the former question you answered
yourself, in the very same conversation.
To summarize what uwog and you said, the priorsync tag is that tag on
HEAD which indicates the point JMM-DOUBLEGRAPHICS-1 was last syncronized
against, which is moved every time the branch is syncronized.

> How is done the merge, because Marc talked about some automatic stuff,
> without being sure.

Again, explained in full before. I may not be a wizbang coder like you
but even _I_ have better things to do for abi than repeat things time
and again if they aren't going to be read.

cvs update [from branch], cvs update [merge changes on head since
priorsync], and if there are no conflicts, cvs commit, tag head [move
priorsync from the old position to the new position].
If there's a conflict, it aborts, uwog or I (or the two of us together)
fixes the conflict and syncs the branch manually, after which normal
operations resume.

> I asked WTF it was. You never dared to reply.

1) You never asked me
2) You seemed to know, based on your conversation with uwog
3) Uwog confirmed it.

I am surprised at all this upset over "priorsync" instead of
"lastmerge". I personally am accustomed to using this tag because I
think it is less ambiguous in indication (the prior syncronization) than
lastmerge (the last merge? merge from-to where? before or after? does
last mean prior, or final? &c) However, if I had known it'd be such a
problem and the word someone else was accustomed to using for the same
thing, I would've just used that.

> > I would ask others to
> > please ignore this tag, as it is not updated with syncronization - the
> > jmm_doublegraphics_1_priorsync tag is.
> Since Marc did not update it, who did it ?

Marc and I both managed this branch, and update it accordingly. Last
time marc had a wee bit of confusion in manually syncronizing the
branch, which has since been worked out, and simply "forgot" to finish
the job by tagging, which is no big deal as we were able to resolve it
(tag HEAD as of when the sync finally occurred) and everything is back
to normal. When he resolves the next pixel-off fix conflict for the
double patch, he'll move the tag again, just like you say he should.

> Re-read. This the _merging tag, not the _lastmerge tag.

Quite right, sorry about that. The superfluous tag made it seem more
like a typo, I failed to look closely enough.

> is, and some arbitrary state of the tree.

If by arbitrary, you mean current.

Received on Wed Dec 29 19:40:53 2004

This archive was generated by hypermail 2.1.8 : Wed Dec 29 2004 - 19:40:53 CET