Using branches

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Using branches

Charles Pope
I am used to using CVSNT, which actually is reasonably intelligent with branches and works well with repeated merges (unlike normal CVS).

I am looking at Mercurial and trying to understand how branches work within a repository. I can see how to name a branch, but I don't understand how you can switch between branches. I don't see a command to move to a different branch. Once I have branches, what is the command to merge changes from one branch into another? I have experimented, but the resultant file doesn't seem to contain any merges.

Is it the case for branches that I really need multiple copies of the repository representing the different branches?

Also, on a side note - is anyone aware of a visual front end like Tortoise on Windows?

Thanks for any advice. I like the feel of mercurial, but I am not clear on its day to day usage.

Charles
Reply | Threaded
Open this post in threaded view
|

Re: Using branches

Matt Mackall
On Thu, Jul 12, 2007 at 12:33:53PM -0700, Charles Pope wrote:

>
> I am used to using CVSNT, which actually is reasonably intelligent with
> branches and works well with repeated merges (unlike normal CVS).
>
> I am looking at Mercurial and trying to understand how branches work within
> a repository. I can see how to name a branch, but I don't understand how you
> can switch between branches. I don't see a command to move to a different
> branch. Once I have branches, what is the command to merge changes from one
> branch into another? I have experimented, but the resultant file doesn't
> seem to contain any merges.

hg up <branch>

> Is it the case for branches that I really need multiple copies of the
> repository representing the different branches?

No, it's just simpler.

--
Mathematics is the supreme nostalgia of our time.
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: Using branches

Dustin Sallings-2
In reply to this post by Charles Pope

On Jul 12, 2007, at 12:33 , Charles Pope wrote:

> I am looking at Mercurial and trying to understand how branches  
> work within
> a repository. I can see how to name a branch, but I don't  
> understand how you
> can switch between branches. I don't see a command to move to a  
> different
> branch. Once I have branches, what is the command to merge changes  
> from one
> branch into another? I have experimented, but the resultant file  
> doesn't
> seem to contain any merges.

        hg update [branchname]

        You probably don't want to do that with uncommitted work.

> Is it the case for branches that I really need multiple copies of the
> repository representing the different branches?

        It's hard to say which way is better.  I come from old-school  
distributed revision control, so multiple-heads within a single tree  
*feels* kind of wrong, but it's not too bad.

--
Dustin Sallings


_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: Using branches

TK Soh
On 7/13/07, Dustin Sallings <[hidden email]> wrote:
>         hg update [branchname]
>
>         You probably don't want to do that with uncommitted work.

OT: I've always felt that a -f/--force option should be added to hg
update to handle uncommit changes.
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: Using branches

Dustin Sallings-2

On Jul 12, 2007, at 16:51 , TK Soh wrote:

> OT: I've always felt that a -f/--force option should be added to hg
> update to handle uncommit changes.

        What would the semantics of -f be?  I understand -C, but where would  
it keep the changes?

        I don't think it could safely carry them across the jump unless you  
wanted to compute a diff, jump, and try to apply it (which may fail  
for numerous reasons).

--
Dustin Sallings


_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: Using branches

Charles Pope
In reply to this post by Matt Mackall
> hg up <branch>

Thanks Matt. Been able to work through some things now.

Charles
Reply | Threaded
Open this post in threaded view
|

Re: Using branches

Charles Pope
In reply to this post by Dustin Sallings-2
> It's hard to say which way is better.  I come from old-school  
> distributed revision control, so multiple-heads within a single tree  
> *feels* kind of wrong, but it's not too bad.

Thank you Dustin. So your preference would be to keep multiple copies, each effectively representing a different branch and then merge changes across, as appropriate?

How does it typically work, when a number of people are sharing the same set of branches? i.e. so all users are clear where to push changes to.

Charles
Reply | Threaded
Open this post in threaded view
|

Re: Using branches

Dustin Sallings-2

On Jul 13, 2007, at 6:38 , Charles Pope wrote:

> Thank you Dustin. So your preference would be to keep multiple  
> copies, each
> effectively representing a different branch and then merge changes  
> across,
> as appropriate?

        Yes.  That's also pretty much what you do in centralized revision  
control systems commonly.  One tree per train of thought.

        Distributed systems make branching like this incredibly cheap,  
therefore you're more likely to do it more often.

> How does it typically work, when a number of people are sharing the  
> same set
> of branches? i.e. so all users are clear where to push changes to.

        This kind of feels more hypothetical.  I wouldn't think a *typical*  
branch would be shared among several developers but perhaps someone  
would want to share some of the work they're doing with someone else  
and can ``hg serve'' it or something.  This is the model that would  
be really useful for me at work.  There have been several times I've  
collaborated with one other person in my group in such a way that  
it'd be harmful for the whole group to see the unfinished work.

        If it's a branch that is common for a lot of developers, you can put  
it up as a different tree.  That's essentially what you do in, for  
example, subversion or perforce.  You get a particular path if you  
want the main branch, and a different path if you want a different  
path.  You can push to one or the other, and merge between them.

        Note that in both of these cases, it's pretty clear:  Push changes  
back whence the tree came.  If you're doing a micro branch, you're  
branching off of a local tree, and you push back into your local tree  
and then push that tree back upstream.  If you're doing a big branch,  
you clone it from an agreed-upon central place, and you push changes  
back there.

--
Dustin Sallings


_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

Re: Using branches

Charles Pope
>>>
        If it's a branch that is common for a lot of developers, you can put  
it up as a different tree.  That's essentially what you do in, for  
example, subversion or perforce.  You get a particular path if you  
want the main branch, and a different path if you want a different  
path.  You can push to one or the other, and merge between them.
<<<

Thanks for your detailed reply. I am thinking about the branches you would have for major releases, which would be shared. In CVSNT we have branches which roughly follow a naming convention, down which we maintain releases (but then we don't really use lightweight branches).

So when you talk about a different tree, this might be a separate clone of the repository representing a particular release (perhaps cloned at the point of release). But in the end the code all originally derives from the same source point so you can move fixes between repositories.

By the way, does the repository have to sit in a parent folder of the source files? The only way I found around this was to use the folder link functionality in windows.

Thanks

Charles