Ending a (Feature) Branch

Eric Berry elberry at gmail.com
Wed Apr 7 06:15:05 BST 2010


On Tue, Apr 6, 2010 at 9:32 PM, Brendan Simon (eTRIX) <
brendan.simon at etrix.com.au> wrote:

>
>  I was thinking of standalone versus shared, but maybe I am confused about
> branches and repositories ??
>

I apologize if I'm not correct in this. I'm not an expert, just a happy user
of Bazaar. From my understanding, a standalone branch is sort of like a
repository in that it contains all the history of that branch and any other
branches that have been merged into it (not considering rebasing). There is
a Bazaar repository which keep track of common history between branches -
very useful when have a lot of separate lines of development, and want to
save some space.


>
> Does it make sense to create a feature branch as a shared branch ??  I'm
> guessing not.
>

Sure, why not? Whatever makes sense for you and your fellow developers.
Where I work, we have "official" branches for each team, and I create
separate feature branches (available on a central repo) when I feel there's
going to be a lot of work that can be done independently. Others contribute
to those feature branches when they can or want to.


> If it was a shared branch, and everything is merged into the parent branch,
> then blowing away the entire shared branch would be fine too, right ??
>

Should be, as long as you let anyone who's bound to that shared branch know
to switch back to the parent branch.


>
> I also noticed that branches can be stacked.  I haven't used a stacked
> branch so I don't know how they really work, except that they depend on the
> availability of the source branch (must be local ?? or can be remote ??).
> My guess is blowing away a stacked branch would not affect the parent branch
> so it has the same affect as a non-stacked branch.
>

I've never used stacked branches before, so I'm not sure how best to use
them.


>
> So the rule is just delete your local branches when not needed any more --
> must merge to parent branch if the changes are to be kept.
>

I'm not sure if it's a "rule", but that's what I do with them once I'm done
working on the features and I've merged them back into the main line.


>
> The only exception seems to be if a feature branch is created in a shared
> repo, and commits are made, and then the branch removed.  The result the
> feature branch is still in the history of the shared repo.
>

Again, I'm not an expert, but I don't think that's how it works. From my
understanding, the repo only keeps the common history (I'm sure it does a
lot more than just that though), all commits made only to that branch should
exist only in that branch.


>
> So is there a 'bzr rmdir' or 'bzr branch --delete' command that would do
> the 'right thing' ... if the repository is shared or not ??
>

'bzr rm' will remove directories and files from version control. If the
branch is a lightweight checkout, there's a 'bzr zap' command provided by
the bzrtools plugin which removes it, but I'm not sure how it's different
than just deleting the branch directory.


-- 
Learn from the past. Live in the present. Plan for the future.
Blog: http://www.townsfolkdesigns.com/blogs/elberry
jEdit <http://www.jedit.org> - Programmer's Text Editor
Bazaar <http://bazaar.canonical.com> - Version Control for Humans
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20100406/888220c3/attachment.htm 


More information about the bazaar mailing list