rename a branch?

[Neal Becker]

On one of my repos, my main branch is called test11. I have no idea why I
called it that. What's the easiest procedure to rename it?

_______________________________________________
Mercurial mailing list
Merc...@selenic.com
http://selenic.com/mailman/listinfo/mercurial

[Masklinn]

On 2012-02-07, at 14:05 , Neal Becker wrote:
> On one of my repos, my main branch is called test11. I have no idea why I
> called it that. What's the easiest procedure to rename it?

Short of rewriting half the repository, I don't think there is one: a branch
in mercurial is metadata attached to the commits themselves, so the best you
can do would be to:

1. Create a new branch from the old one with the correct name
2. Close the old branch so it does not appear in branch listings by default

commits made on the old branch will still have the old branchname though,
they will not be taking the new one.

(bookmarks, merely being movable pointers to a commit, can be renamed easily)

[Jeff Dyke]

On Tue, Feb 7, 2012 at 8:31 AM, Masklinn <mask...@masklinn.net> wrote:
> On 2012-02-07, at 14:05 , Neal Becker wrote:
>> On one of my repos, my main branch is called test11.  I have no idea why I
>> called it that.  What's the easiest procedure to rename it?

This happened to me as well during a SVN->HG conversion
I had everyone check in all of their changes and performed a
HG->HG Conversion utilizing the --branchmap mapfile option and the
closing the branch. This leaves the test11 branch live in previous
commits
but going forward all commits happen on default.

If you take this route you will still see test11, but there will also
be a new branch called default, so then its simple to do a final merge
with --close-branch.

HTH
Jeff

[Neal Becker]

Let me give a more complete description

I have a repo where I am testing the idea of keeping 2 branches, 1 is the
upstream vendor updates, and the other is my local changes on top of them.

I have a branch called 'default', which is actually my upstream vendor branch.

I have a branch called 'test11', which really is my local changes, and I really
want that to be 'default'.

Here's what I tried:

First a made a new clean repo using clone.

Then in that repo I made a new branch 'vendor'.

Then I copied a newer vendor source version on top of these files.
Then addremove, and ci -m 'update to ...'. Now I have a vendor branch with
updated vendor source.

Then I update to default (that was my old vendor branch).

Then merge with test11, pulling all my local changes into default.

Finally, merge with 'vendor', pulling the new vendor changes into my default.

I think that's got it. Does this sound correct?

[Jeff Dyke]

On Tue, Feb 7, 2012 at 9:31 AM, Neal Becker <ndbe...@gmail.com> wrote:
> Let me give a more complete description
>
> I have a repo where I am testing the idea of keeping 2 branches, 1 is the
> upstream vendor updates, and the other is my local changes on top of them.
>
> I have a branch called 'default', which is actually my upstream vendor branch.
>
> I have a branch called 'test11', which really is my local changes, and I really
> want that to be 'default'.
>
> Here's what I tried:
>
> First a made a new clean repo using clone.
>
> Then in that repo I made a new branch 'vendor'.
>
> Then I copied a newer vendor source version on top of these files.
> Then addremove, and ci -m 'update to ...'.  Now I have a vendor branch with
> updated vendor source.
>
> Then I update to default (that was my old vendor branch).
>
> Then merge with test11, pulling all my local changes into default.
>
> Finally, merge with 'vendor', pulling the new vendor changes into my default.
>
> I think that's got it.  Does this sound correct?

It does to me. I ran into an issue where i had no default branch, so
i explicitly did a new (hg->hg) conversion and all of my dev's are in
house so it was simple to have them stop for a bit while this ran. As
long as you have your branches where you want them to be and your
vendors are in the know, you're rockin. Not having 'default' in my
brand new environment just felt a dirty way to start a new
implementation, so i opted for the convert.

Props to the HG devs for the convert command and the maintaing of
history, great feature!