Re: [PanoTools-devel] error on Hg push

hi Jim,
>From what I have read, just use -f to force it.
We just have to be careful when we check out to use the proper "tip".
--dmg
On Sun, Feb 13, 2011 at 8:11 AM, Jim Watters <jwatters@...> wrote:
> Hg. But I keep going to the command line when they
> decide to use different names in the GUI and I cant find what I need to do.
> I Created a new branch to upload my changes to using
> hg branch PhotoshopPSB
> I pulled down changes using synchronize
> I committed my changes locally.
> hg pull [to get other changes. There was some on the optimizeroptions branch I
> believe]
> I continued to commit my changes.
> hg pull [no more changes]
> I have verified my changes with hg outgoing
> But when I try to do a push I get the following.
>
--
--dmg
---
Daniel M. German
http://turingmachine.org

Thread view

I am tying to use TortoisHg. But I keep going to the command line when they
decide to use different names in the GUI and I cant find what I need to do.
I Created a new branch to upload my changes to using
hg branch PhotoshopPSB
I pulled down changes using synchronize
I committed my changes locally.
hg pull [to get other changes. There was some on the optimizeroptions branch I
believe]
I continued to commit my changes.
hg pull [no more changes]
I have verified my changes with hg outgoing
But when I try to do a push I get the following.
D:\source\panotools hg\libpano>hg push
pushing to ssh://jim0watters@.../hgroot/panotools/libpano
searching for changes
abort: push creates new remote heads!
(did you forget to merge? use push -f to force)
I found this [0]FAQ that suggest three alternatives and force is no one of them.
I tried hg pull --rebase and hg merge but I don't understand the problem.
Why is optimizeroptions listed twice in heads?
D:\source\panotools hg\libpano>hg heads
changeset: 691:89bcc32a42b8
branch: optimizeroptions
tag: tip
parent: 680:1d5004761d96
user: dmg <dmg@...>
date: Fri Feb 11 11:08:57 2011 -0800
summary: Added commnad line options to PToptimizer.
changeset: 690:9b9b3887cddf
branch: PhotoshopPSB
user: Jim Watters
date: Sun Feb 13 01:32:46 2011 -0400
summary: Use 8byte sizes all the time.
changeset: 682:f0891e225424
branch: optimizeroptions
user: Bruno Postle <bruno@...>
date: Wed Feb 09 22:59:49 2011 +0000
summary: Update ChangeLog
changeset: 676:89e2ee12bfea
branch: libpano
user: dangelo
date: Thu Jan 20 20:24:25 2011 +0000
summary: removed debug printf
[0] https://developer.mozilla.org/en/Mercurial_FAQ
--
Jim Watters
http://photocreations.ca

hi Jim,
>From what I have read, just use -f to force it.
We just have to be careful when we check out to use the proper "tip".
--dmg
On Sun, Feb 13, 2011 at 8:11 AM, Jim Watters <jwatters@...> wrote:
> Hg. But I keep going to the command line when they
> decide to use different names in the GUI and I cant find what I need to do.
> I Created a new branch to upload my changes to using
> hg branch PhotoshopPSB
> I pulled down changes using synchronize
> I committed my changes locally.
> hg pull [to get other changes. There was some on the optimizeroptions branch I
> believe]
> I continued to commit my changes.
> hg pull [no more changes]
> I have verified my changes with hg outgoing
> But when I try to do a push I get the following.
>
--
--dmg
---
Daniel M. German
http://turingmachine.org

Hi Yuv,
the optimizeroptions branch was not meant to be merged yet. It is
going to be used for testing for a while.
Can you please undo that commit?
--dmg
2011/2/13 Yuval Levy <sf05@...>:
> On February 13, 2011 11:17:04 am dmg wrote:
>>
>> >From what I have read, just use -f to force it.
>>
>> We just have to be careful when we check out to use the proper "tip".
>
> "tip" is just a tag that get set on the latest commit. One should never check
> out "tip". If you work on branch A and I work on branch B, if you are the
> last committer "tip" will be branch A and if I am the last committer tip will
> be branch B.
>
> As a rule, you want to always `hg pull && hg up` before `hg push`.
>
> If the system notifies you of multiple heads to the same branch, like in this
> situation, you want to `hg merge` before pushing.
>
> I just solved the problem with:
> hg pull
> hg up
> hg merge
> hg ci
> hg push
>
> As a committer, you want to look at your own tree with `hg view`
>
> It will show something like:
>
> http://panotools.hg.sourceforge.net/hgweb/panotools/libpano/graph
>
> when you see unintended additional heads (i.e. if you have not branched out
> and there are more heads), you want to go through `hg merge` and `hg ci`
> before pushing.
>
> @Jim: do you have access to "hg view" or something similar in TortoiseHg?
>
> @Bruno: your two commits (added more files to the tarball; and updated
> ChangeLog) where they really intended for the optimizeroptions branch? or for
> the libpano branch?
>
> when not sure on which branch you are:
> hg banches - lists all branches
> hg branch - tells you which branch you are on
> hg up -C <BRANCHNAME> - puts you on that branch
>
> I see only two branches inside the libpano repo:
> - optimizeroptions
> - libpano
>
> I look forward to see PhotoshopPSB after Jim pushes it.
>
> In "canonical" Hg repos there is a 'default' branch. The equivalent to SVN's
> 'trunk'. We don't have it here, so we have to double check on which branch we
> are before making and committing changes.
>
> Yuv
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> PanoTools-devel mailing list
> PanoTools-devel@...
> https://lists.sourceforge.net/lists/listinfo/panotools-devel
>
>
--
--dmg
---
Daniel M. German
http://turingmachine.org

Hi Daniel,
On February 13, 2011 12:22:38 pm dmg wrote:
> the optimizeroptions branch was not meant to be merged yet. It is
> going to be used for testing for a while.
>
> Can you please undo that commit?
I think we have a major misunderstanding here. I see two branches:
- libpano, last updated three weeks ago (and "inactive" until my changes
listed below)
- optimizeroptions, which had two heads and which I have merged into a single
one.
The merge need not be undone.
What need to be done is proper branching. This is what I did
hg up -C libpano
hg export --git 681 | hg import -
hg push -f
hg branches
now the branches are all active as they should have been.
When you branch out a new branch, e.g.
hg branch optimizeroptions
You must push that new branch to the repo with
hg push -f
else the old branch will be simply declared "inactive" and the new branch will
be a "rename" of the old branch; and people working on the two branches will
"compete" for attention.
The
hg export --git 681 | hg import -
I did was to commit a change that was probably meant to "trunk" to the main
libpano. If you think that that change, and the updated changelog, do not
belong in "optimizeroptions", feel free to revert them.
Yuv

Hi Yuv,
You have been the main champion of mercurial so far :) so you are our expert.
We need the original trunk (libpano) to be the HEAD of trunk. This is
getting ready for a release, which
Bruno is handling.
optimizeroptions is a branch that cannot be merged with libpano
because it has code that can
break that release.
when you say that the commit does not need to be undone, does that
mean the repository is working
as described above?
2011/2/13 Yuval Levy <sf05@...>:
> hg branch optimizeroptions
>
> You must push that new branch to the repo with
>
> hg push -f
>
That is what I had to do in my previous push, and why I suggested to
Jim to do the same. But I don't recall if I did it the first time.
My original conversion resulted in the "trunk" (libpano). That was the
name given by the svn2hg converter.
My trunk optimizeroptions was started with hg branch.
I guess the question is, how do we turn "libpano" into the trunk, and
Jim and my branches into real branches.
--
--dmg
---
Daniel M. German
http://turingmachine.org

Hi Daniel,
On February 13, 2011 07:24:00 pm dmg wrote:
> We need the original trunk (libpano) to be the HEAD of trunk. This is
> getting ready for a release, which Bruno is handling.
AFAIK he handled a release of Hugin on Mercurial, so it won't be much
different. I suggest he branch out the release, like we do for Hugin.
> when you say that the commit does not need to be undone, does that
> mean the repository is working
> as described above?
Yes.
Yuv

On Sun 13-Feb-2011 at 16:24 -0800, Daniel M. German wrote:
>
> We need the original trunk (libpano) to be the HEAD of trunk. This is
> getting ready for a release, which
> Bruno is handling.
I'd still like to have the test suite merged first. I can just copy
the files if we are not concerned about the history (this is how it
would have been in SVN anyway).
--
Bruno

Hi Yuv,
thanks. it seems that your magic worked. I checked again and now we
have three different ends of the graph
(whatever they are called in hg). Is there a way to always force
libpano to be the "tip"? or do we
always have to be careful not to write to the one branch?
thanks again?
--dmg
On Sun, Feb 13, 2011 at 4:24 PM, dmg <dmg@...> wrote:
> Hi Yuv,
>
> You have been the main champion of mercurial so far :) so you are our expert.
>
> We need the original trunk (libpano) to be the HEAD of trunk. This is
> getting ready for a release, which
> Bruno is handling.
>
> optimizeroptions is a branch that cannot be merged with libpano
> because it has code that can
> break that release.
>
> when you say that the commit does not need to be undone, does that
> mean the repository is working
> as described above?
>
> 2011/2/13 Yuval Levy <sf05@...>:
>> hg branch optimizeroptions
>>
>> You must push that new branch to the repo with
>>
>> hg push -f
>>
>
>
> That is what I had to do in my previous push, and why I suggested to
> Jim to do the same. But I don't recall if I did it the first time.
>
> My original conversion resulted in the "trunk" (libpano). That was the
> name given by the svn2hg converter.
>
> My trunk optimizeroptions was started with hg branch.
>
> I guess the question is, how do we turn "libpano" into the trunk, and
> Jim and my branches into real branches.
>
>
> --
> --dmg
>
> ---
> Daniel M. German
> http://turingmachine.org
>
--
--dmg
---
Daniel M. German
http://turingmachine.org

Hi Daniel,
On February 13, 2011 09:02:15 pm dmg wrote:
> thanks. it seems that your magic worked.
not my magic. It's Mercurial. Awesome SCM.
> Is there a way to always force libpano to be the "tip"?
not that I know.
> or do we
> always have to be careful not to write to the one branch?
one always need to know what branch their are working in. When in doubt, `hg
branch` has the answer. `hg branches` lists them all and `hg up -C
<BRANCH_NAME>` get you on a particular branch. `hg up -r <REV#>` gets you to
a particular revision, and a revision is always associated with the one branch
it was committed to.
If you want to work on multiple branches at the same time, I recommend [0].
Yuv
[0] http://panospace.wordpress.com/2011/02/13/local-transparent-cache-of-a-
mercurial-repos/