Re: VCS comparison table

On 10/22/06, Jakub Narebski [off-list ref] wrote:

Erik Bågfors wrote:

quoted

Jakub Narębski wrote:

quoted

quoted

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/

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.

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.

This is typically how all features in bzr are created.
Short/medium/long-lived feature branches.

/Erik