Andrew Beekhof wrote:
> On 11/14/06, Alan Robertson <[EMAIL PROTECTED]> wrote:
>> Andrew Beekhof wrote:
>> > In light of this thread, I was somewhat surprised to see this:
>> > http://hg.linux-ha.org/dev?cs=5efbd40c99db
>>
>>
>> Me too. If you'd have been around I'd have tried to find out what this
>> was about.
>>
>> What happened was this:
>>
>> I did a commit.
>> I tried to push to -dev
>> I was informed that I needed to pull first
>> I did the pull from -dev
>> I was informed I needed to merge some things together.
>> I issued the merge command.
>> There were no conflicts, so I didn't have to do anything
>> manually.
>> Then I had to commit the things I had to merge and push
>> them back to -dev.
>>
>> I have NO IDEA what this was about. It sounds a bit
>> like a bug to me... :-(
>>
>> Can anyone give me a clue about this?
>
> Which part dont you understand?
Basically none of it.
If the change is already in the tree, and doesn't affect ANY files I
touched, then it's completely broken for it to ask me to merge changes
ALREADY IN THE TREE back into the tree. I CANNOT POSSIBLY make a
coherent comment on these changes I don't have the slightest clue about.
They were already there - I'm just putting them back. OK, this is a
little broken. And, I have to re-explain what these changes do??? This
is never going to happen. I have no idea what these changes do - and no
way to find out. If the merge can happen automatically, then the
comments need to happen automatically too...
If I put the bugzilla number for that bug, then you'll mistakenly think
I made those changes, and that they have something to do with that bug -
when neither is true. This is a HUGE breakage. But, maybe I need to
know how to properly comment on such merge changes...
> Just because the merge was done automatically, you still need to
> commit it to join the two (albeit short) lines of development
> together.
Hg needs to get a clue: No files in common == nothing to join.
> I've attached a jpeg of roughly what's happening...
>
> Each circle is a commit.
> A, B : commits common to both repositories
> C, D : commits made since your last pull
> E, F : your commits
>
> G is the merge commit for which the message should read something like:
> Hg: Merge local changes back into dev
> or:
> Hg: Merge crm-stable into dev
> or:
> Hg: Merge dev back into crm-stable
OK. All I said was "Merge???". As long as merges aren't supposed to
have bugzilla numbers on them, then I'm OK. So the process should be
like this:
make your changes
test them
commit them locally (and selectively)
pull upstream changes
commit them with a special comment - while carefully excluding
any other changes in your workspace you don't want
to accidentally commit as part of the merge.
(FWIW: sounds error-prone to me)
push changes upstream - hoping no one else did any pushes
since step 4. If they did, then repeat from
step 4 until it works.
Many developers pushing near a deadline may make
this take 2 or 3 tries to work.
Is that right?
So, the only thing I got wrong here was the text of the comment. And,
it wasn't that far off.
> On a related note, this can be a particularly useful command:
> hg log -M -r STABLE-2.0.7:tip --template "*
> {desc|firstline|strip} - {author}\n"
>
> ...particularly if we prefix the first line of the commit with the
> name of the affected heartbeat subsystem and the bug being fixed.
>
> eg. here are all the bugzillas we've fixed since 2.0.7
>
> # hg log -M -r STABLE-2.0.7:tip --template "*
> {desc|firstline|strip}\n" | grep OSDL
> * OSDL 1412: Remove reliance on farside_pid by stonithd
> * RA: Fix for OSDL 1422 - refresh interval off by a factor of 1000
> * CIB: Fix for OSDL #1432 - update_attr() causes attrd to hang at
> shutdown when there is no DC
> * CIB: Fix for OSDL #1385 - Corrupted config file prevents heartbeat
> restart
> * OSDL #1441: Spec file fixes
> * OSDL #1421: Improved handling when timeout < start_delay
> * OSDL #1435 - Fix TE regression, never update the CIB with
> unconfirmed stop actions
>
>
> i'm sure people can see how this might make writing change logs a
> little easier - provided we write good commit messages (especially
> since with Hg there is one log per changeset instead of "per file per
> changeset").
I can see how that tool helps. I can't see why I need to re-comment on
changes that have already been commented on, and I have no idea about.
I can't see why if there are ZERO files in common, why I have to remerge
them.
Hg is nice in lots of ways. Being fast is high on the list. But, this
business is broken, IMHO.
Please understand that although I'm irritated, my irritation isn't at
the people on this mailing list.
--
Alan Robertson <[EMAIL PROTECTED]>
"Openness is the foundation and preservative of friendship... Let me
claim from you at all times your undisguised opinions." - William
Wilberforce
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
