On 22/08/10 00:30, Benjamin R. Haskell wrote:
On Sat, 21 Aug 2010, Xavier de Gaye wrote:
On Sat, Aug 21, 2010 at 6:48 PM, Tony Mechelynck wrote:
On 18/08/10 14:49, Xavier de Gaye wrote:
Actually, having multiple heads in the same branch may be
considered as not a problem. When we have local changes, after
pulling from the official repository, in order to merge the new
official changesets into our own local changes, we now have to run
(where<highest revision number> is given by 'hg heads' for
example):
hg merge -r<highest revision number>
instead of previously with only one head:
hg merge
Also, with multiple heads in the current branch, the "fetch"
extension cannot be used: instead of one command
hg fetch --switch-parent
you have to run three
hg pull -u
hg merge -r ab3fc5de6b49
hg commit -m 'merge for patchlevel 7.3.004'
and the text for the latter two (or at least for the middle one)
varies every time.
You may also run:
hg pull
hg merge -r tip
hg commit -m 'Automated merge with http://vim.googlecode.com/hg/'
Nothing varies in the above three statements, and these statements can
go in a 'my_fetch.sh' script.
This seems overly complicated for one of the most common things one does
with a repository. (get changes from upstream)
Isn't this essentially what the fetch extension does? (So the above
becomes: hg fetch) Or was this not working when there were two heads?
hg fetch does that without the "-r tip" switch to merge, failing if the
merge doesn't see exactly two heads (one with local changes and one
newly pulled) on that branch. If the remote "master" repo has two heads
for the branch, it fails as soon as you have local changes (as I have in
.hgignore and src/feature.h).
The fetch extension has been implemented so as to emulate the behavior
of 'git pull', for people familiar with git I guess. In git, you pull.
In mercurial you pull, then merge or update or wait until a more
appropriate time. Your choice. Mercurial looks more flexible in this
matter. I don't see it as a problem.
Actually, it seems like hg fetch (pull in new changes, merge if needed)
is roughly equivalent to git pull (fetch new changes, merge if needed).
So, confusingly:
hg pull ~= git fetch
hg fetch ~= git pull
In Gitopia, you fetch changes from the remote server, then pull them
into your local work. In Mercurialand, you pull changes from the remote
server and then fetch(?) them into your repository. (My preferred
nomenclature bias might be evident, here.)
hg fetch ~= hg pull && hg merge && hg commit -m "Automated merge from
${paths.default}"
In Mercurialand, you pull new metadata into your repository then locally
update your working directory. Or maybe merge outstanding topological
branches then commit the result. Fetching is a nondefault extension,
roughly equivalent to pull+merge+commit, chiefly (IMHO) for use on
pull-only repositories with local changes. (By pull-only I mean that you
won't need to push from them.)
Also, in Mercurialand (and assuming the necessary privileges are set) if
repositories A and B are related (by one being a clone of the other, or
both clones of a 3rd one) pushing and pulling are reciprocal operations:
if user A pushes from his repo to to repository B, or user B pulls from
repository A, the result is supposed to be the same.
Best regards,
Tony.
--
"They told me I was gullible ... and I believed them!"
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
