Re: [Linux-ha-dev] Recommended Hg/Bugzilla policy
On 2006-11-14T08:20:53, Alan Robertson [EMAIL PROTECTED] wrote: 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. This is not what is happening. Your changes and the one in the other repo are both equivalent lines of development, but you want to merge them into a single tip again - and end both independent lines. This is where the merge is occuring; you're not putting them back, you're merging them. hg can't know that they are independent. Sure it sees they are not touching the same files, but this isn't the same. This follows from the distributed repo approach. You don't need to comment on the specific changes merged. It's sufficient to comment it with Merging my development branch with dev. or some such. The hg log still has the history for both branches, so you don't need to repeat it. 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. Feel free to argue this position upstream, but I doubt it will fly. OK. All I said was Merge???. As long as merges aren't supposed to have bugzilla numbers on them, then I'm OK. They don't have to, but they should say which branches you merged. So the process should be like this: make your changes test them commit them locally (and selectively) You already created a new branch at this point, btw. You don't tend to commit selectively with hg (or another distributed SCM). You have independent changes in independent workspaces, and you merge them as necessary. 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) Uhm. No. You pull, update, and merge. I don't see why you'd need to exclude anything. 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? No. There's several steps in there I don't even get. But, you seem to be operating on the assumption that merges are bad, and want to avoid them. I don't see why - merges are a part of distributed SCMs. They don't need to be avoided. So, the only thing I got wrong here was the text of the comment. And, it wasn't that far off. Andrew has been asking for better comments on merges several times on the list though. It doesn't really work well to propose changes to the commit policies and ignore those improvements already made ;-) Maybe you simply missed those mails. 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. Again, you don't. I can't see why if there are ZERO files in common, why I have to remerge them. Because zero files in common does not equal same line of development. Sincerely, Lars Marowsky-Brée -- SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin Ignorance more frequently begets confidence than does knowledge. ___ 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/
Re: [Linux-ha-dev] Recommended Hg/Bugzilla policy
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
Re: [Linux-ha-dev] Recommended Hg/Bugzilla policy
On 2006-11-13T16:51:07, Alan Robertson [EMAIL PROTECTED] wrote: 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've had this happen to myself. What happens is that your commit is relative to an older revision (ie, one which has several children), and not relative to the tip. If you commit at that stage, you create a branch in the upstream repo (which is how I screwed up ;-); so merge first. The sequence you went through is actually correct, but the merge message is ... uhm ... ;-) I have NO IDEA what this was about. It sounds a bit like a bug to me... :-( It's not a bug (I once had a branch I couldn't merge back myself; that probably was a bug ;-), but a different modus operandi. Only when you commit and push relative to the tip can you avoid this, which isn't likely to happen if the changes take a while to work out. So, this is something to get used to: history isn't always linear. Sincerely, Lars -- SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin Ignorance more frequently begets confidence than does knowledge. ___ 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/
Re: Re: [Linux-ha-dev] Recommended Hg/Bugzilla policy
In light of this thread, I was somewhat surprised to see this: http://hg.linux-ha.org/dev?cs=5efbd40c99db Particularly given some other emails I have sent to this list on the topic. On 11/9/06, Alan Robertson [EMAIL PROTECTED] wrote: Lars Marowsky-Bree wrote: On 2006-11-07T08:17:10, Alan Robertson [EMAIL PROTECTED] wrote: I'd like to suggest what I think is a simple but useful policy for dealing with commits to Mercurial which correspond to bug reports. I've tried getting people to agree to bugzilla SCM policies/guidelines for more than several months, but in the past, nobody ever sticked to them. ;-) So, yes, I think including the bug number in the commits in the first line is a great idea, and I love to see that you're finally agreeing. I never disagreed on this. But, I'm always happy to give you a reason to complain ;-) 3) For each bug which has been marked as fixed, the changeset submitted to -dev should be indicated by URL. An example of what I mean can be found in OSDL bugzilla 1443. Yes, providing the backlink is good, but having it in the commit message is what I consider most important. http://www.osdl.org/developer_bugzilla/show_bug.cgi?id=1443 Note that in this case, it took me two changesets to really resolve the bug. Both are indicated in the bugzilla. This bug doesn't follow my suggested guidelines perfectly - in the 2nd changeset it just says Bugzilla 1443 instead of OSDL 1443. The appearance of the # sign would also be an improvement, I think... I don't think we really need the #. It makes cutpaste more annoying (# is included if you double-click on the word), and and everyone knows that, well, it is a number, so it is sort-of redundant. In an ideal world these things could be followed consistently enough that one could write a tool that given any changeset could find the bugzilla for it and vice versa. But, failing that, it would be good if humans could do it quickly and easily. Yes. I'd also like to point out that commit messages of user-visible changes should always include an update to the changelog in the spec file. Sounds really good to me, since otherwise I have to put them in the ChangeLog myself - and that's my least favorite part of this release process. -- 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/ ___ 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/
Re: [Linux-ha-dev] Recommended Hg/Bugzilla policy
Lars Marowsky-Bree wrote: On 2006-11-07T08:17:10, Alan Robertson [EMAIL PROTECTED] wrote: I'd like to suggest what I think is a simple but useful policy for dealing with commits to Mercurial which correspond to bug reports. I've tried getting people to agree to bugzilla SCM policies/guidelines for more than several months, but in the past, nobody ever sticked to them. ;-) So, yes, I think including the bug number in the commits in the first line is a great idea, and I love to see that you're finally agreeing. I never disagreed on this. But, I'm always happy to give you a reason to complain ;-) 3) For each bug which has been marked as fixed, the changeset submitted to -dev should be indicated by URL. An example of what I mean can be found in OSDL bugzilla 1443. Yes, providing the backlink is good, but having it in the commit message is what I consider most important. http://www.osdl.org/developer_bugzilla/show_bug.cgi?id=1443 Note that in this case, it took me two changesets to really resolve the bug. Both are indicated in the bugzilla. This bug doesn't follow my suggested guidelines perfectly - in the 2nd changeset it just says Bugzilla 1443 instead of OSDL 1443. The appearance of the # sign would also be an improvement, I think... I don't think we really need the #. It makes cutpaste more annoying (# is included if you double-click on the word), and and everyone knows that, well, it is a number, so it is sort-of redundant. In an ideal world these things could be followed consistently enough that one could write a tool that given any changeset could find the bugzilla for it and vice versa. But, failing that, it would be good if humans could do it quickly and easily. Yes. I'd also like to point out that commit messages of user-visible changes should always include an update to the changelog in the spec file. Sounds really good to me, since otherwise I have to put them in the ChangeLog myself - and that's my least favorite part of this release process. -- 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/
Re: [Linux-ha-dev] Recommended Hg/Bugzilla policy
On 2006-11-07T08:17:10, Alan Robertson [EMAIL PROTECTED] wrote: I'd like to suggest what I think is a simple but useful policy for dealing with commits to Mercurial which correspond to bug reports. I've tried getting people to agree to bugzilla SCM policies/guidelines for more than several months, but in the past, nobody ever sticked to them. ;-) So, yes, I think including the bug number in the commits in the first line is a great idea, and I love to see that you're finally agreeing. 3) For each bug which has been marked as fixed, the changeset submitted to -dev should be indicated by URL. An example of what I mean can be found in OSDL bugzilla 1443. Yes, providing the backlink is good, but having it in the commit message is what I consider most important. http://www.osdl.org/developer_bugzilla/show_bug.cgi?id=1443 Note that in this case, it took me two changesets to really resolve the bug. Both are indicated in the bugzilla. This bug doesn't follow my suggested guidelines perfectly - in the 2nd changeset it just says Bugzilla 1443 instead of OSDL 1443. The appearance of the # sign would also be an improvement, I think... I don't think we really need the #. It makes cutpaste more annoying (# is included if you double-click on the word), and and everyone knows that, well, it is a number, so it is sort-of redundant. In an ideal world these things could be followed consistently enough that one could write a tool that given any changeset could find the bugzilla for it and vice versa. But, failing that, it would be good if humans could do it quickly and easily. Yes. I'd also like to point out that commit messages of user-visible changes should always include an update to the changelog in the spec file. Sincerely, Lars -- SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin Ignorance more frequently begets confidence than does knowledge. ___ 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/
Re: [Linux-ha-dev] Recommended Hg/Bugzilla policy
Zhen Huang wrote: I think it's a good idea to unify the commit comments. I would like to follow them. BTW, sorry for the unclear comment GUI: Fix OSDL 1415: use xxx-xxx-xxx to replace xxx_xxx_xxx (http://hg.linux-ha.org/dev?cmd=changeset;node=64516dbe675b). It should be use new attribute name like xxx-xxx (like stonith-enabled) to replace old name xxx_xxx(like stonith_enabled) Strangely enough, I figured it out anyway ;-) I wasn't picking on you -- just making a suggestion to see what everyone thinks. -- 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/
