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: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
