Re: [glob2-devel] Woes with Mercurial

[Kai Antweiler]

> Ok, i just did a branch on my local copy:
> hg branch core_rewrite_2007
>
> Then I commit
> hg commit -m"Branched core rewrite"
>
> Then I pushed:
> hg push -r core_rewrite_2007 https://hg.globulation2.org/glob2
>
> Is this correct?

Yes.


> My changes still make the global tip of the
> respitory, is the idea that tip of the master branch hasn't changed?

I'm not sure what you mean.  Important in our case is, that the most recent
revision of the master branch does not come from experimental code.
When you have an other named branch that poses the tip, that's OK.
"hg pull -r master ..." won't see it.
And "hg pull -r master ..." will not pull all revisions in the master
branch either!!!
It will look for the most recent pushed revision with the master tag, and pull
all revisions that it depends on.
Your attempt to revert all your changes and merge the result with the tip
was therefore suboptimal.  The result depended on the 30+ revisions of your
rewrite branch.

I have pushed a new tip that does not.

Multiple heads in our repository are no problem, you should only merge
when you want to - not when mercurial tells you to do it.


> Does this mean people who cloned without -r will get my changes? Thats
> how I see it atleast.

Yes.  Therefore anyone who wants to play glob2 must use the "-r master"


> Forgive me If i still don't understand the development model. What I
> should do, I think, is to clone the entire respitory, and pull from
> globulation2.org server frequently. Then clone individual branches,
> with -r.
> With the master branch, i would simply pull from my incoming and
> update. I wouldn't do any updating with my incoming respitory, just
> pulling changesets.

That's what I do.


> Then I would work on my branch, occassionally pulling from the master
> branch and merging back in. I would frequently pull from my incoming
> with -r to get anyone elses changes on my branch, and occassionally
> push to the respitory with -r.

I would try only to merge in those changes from other people that have a
high chance of getting into the master branch one day.  Otherwise you'll
get trash into your branch.

I also recommend to use an "outgoing" repository. That is a good place
to play with
the repository structure.
Also use "hg view, hg log, hg outgoing, hg branch, hg branches, hg heads" to get
an impression of what your doing.
If something looks weird in your outgoing branch, just ask in the mailing list.
Good thing about distributed scms is that you can test everything before pushing
it into the rest of the world.


> When I want to merge back in, I take my master and pull from my
> branch, then push to the server with that.

This would merge your changes into master.  So you should do this only
when your confident of your work.


> Is the incoming really nesseccarry? Seems like just extra work to do
> the same thing.

Necessary: no.
Convenient: yes.
Especially for people with low bandwidth.
Also I don't want to have multiple branches in my working directory.
This will only cause mercurial to get on your nerves, by commanding you
to merge and giving bad results when using "hg status", "hg diff" or
"hg bisect".
If you only pull the things into your working directory, you can look
why mercurial
wants you to merge and decide if you want to.
For players incoming is redundant.

--
Kai Antweiler