Erik Bågfors wrote:
> On 10/22/06, Jakub Narebski <jnareb@xxxxxxxxx> wrote:
>> Erik Bågfors wrote:
>>> Jakub Narębski wrote:
>>
>>>> For example git encourages using many short and longer-lived feature
>>>> branches; I don't see bzr encouraging this workflow.
>>>
>>> Why not? I think it really does. And due to the fact that merges are
>>> merges and will show up as such, I think it's very suitable for
>>> feature branches.
>>
>> I think I haven't properly explained what "feature branch" means.
>> "Feature branch" is short (or medium) lived branch, created for
>> development of one isolated feature. When feature is in stable
>> stage, we merge feature branch and forget about it. We are not
>> interested in the fact that given feature was developed on given
>> branch. BTW. for example in published git.git repository are
>> only available in the form of "digest" 'pu' (proposed updates)
>> branch.
>
> That's what I'm talking about too.
> For example, in my bzr bzr-repo I have
> bzr.init-repo-tree/
> bzr.aliases/
> bzr.dev/
Due to the fact that git uses separate namespace for branch names,
and not position on filesystem, one would probably use 'dev'
(or 'master', or perhaps 'next'), 'aliases' and 'init-repo-tree'
as branch names. No need for 'bzr.' prefix to distingush
branches from other directories for user.
Git does use convention like above for bare repositories
(clones of repositories without working tree; working tree
is associated with repository, not with branch), e.g. git.git
or linux-2.6.18.y.git though.
> and others...
> In bzr.aliases for example, I built the support for defining aliases
> in the bzr config file. That was a unique feature that didn't exist in
> any other branch. The branch survived about 17 days before it was
> merged into bzr.dev. During that time, I merge in another branch
> twice. The branch I merged at this time was NOT bzr.dev, but rather
> another branch, from one of the main developers. The reason I merged
> his branch was that I needed a bugfix (or two? :) ) that he had done,
> but that wasn't approved in bzr.dev yet.
That is also quite common. Merging 'master' into feature branch,
or 'next' into feature branch. One could of course cherry-pick
only the bugfix... can you do this in bzr?
> After a time, his branch was merged into bzr.dev, shortly thereafter,
> so was my branch.
>
> After my branch was merged, I forgot about it. I still have it laying
> around on my computer because it really doesn't take up any extra
> space (since it's in a shared repository), but I really have forgotten
> about it.
Usually after feature branch is merged (or fast-forwarded) we delete
it. All the parentage information is in DAG anyway. We can later
attach new branch with the same name to the point where the branch was.
> This is typically how all features in bzr are created.
> Short/medium/long-lived feature branches.
Like I said, in git.git development we use development branches
(e.g. 'master', 'maint', 'next'), tracking branches (e.g. 'origin',
'linus'), feature branches (e.g. 'jc/pickaxe', 'np/pack'), "helper"
branches storing somewhat unrelated ('html' and 'man' branches for
autogenerated documentation) or unrelated ('todo' for TODO notes)
wtr. code stored to the main project, "digest" branches (e.g. 'pu'
branch in git.git, which is merge of WIP feature branches to be
published, and does not fast-forward), and temporary branches (for
example for shelving current work).
>From long, to medium, to short, to extremly short lived.
--
Jakub Narebski
Poland
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html