Handling concurrent changesets/activitieson one branch in bazaar

Hi Tom,

So if I understand correctly, you want to have one source tree but have different files or subdirectories within it that are checked out from and going to be committed to one branch, and others that will go onto another.

Bazaar's basic model is that the whole tree comes from one branch, and we think this is a good thing because it encourages you to be sure that what's committed to the branch is in fact a tree that existed on disk and was tested or written together. However, there are various things we can do.

If you use a loom or pipeline, then the top/final stage will contain the integration of all the changes up to that point, so you will be able to see everything together.

On unix, if you have multiple working trees, you can make them use less space by branching with --hardlink so the working files share disk storage.

If you have changes in a single tree you can pick them out of there using 'bzr merge --uncommitted' to move them into a different tree - or also shelve, looms, pipelines, etc.

You may find that checking out and changing files is faster in Bazaar than in Clearcase and so the performance envelope is different.

I hope that helps, please feel free to ask more.

Hi Martin,

Thanks for your helpful suggestions. I've since worked a bit more with pipes and looms (and shelving) and have found these features to be beneficial for our workflow. The main issue we have and want to solve, is the organisation of concurrent changeset on the one branch.

As you said Pipes and looms help this by staging a workflow which build up into one staging area which contains all concurrent changes. This is quite good, however changing contexts within these workflows changes our working tree (based on which stage we're looking at in the quilt/pipeline). One unusual problem for us is that our large source takes quite a long time to build. So you can imagine as a developer, frequently changing contexts and changing different files means we're doing a lot of rebuilding of our continually changing working tree. Even so, there is a bit of time overhead switching between contexts within the pipeline, as it does updates/deletes to get the working tree to reflect the current stage you're on (and again, having a large number of files to build and then updating) which can be a slowdown to development.

As example, with what we're used to, in Clearcase UCM, you can have multiple concurrent activities and can change activities of work quickly, while keeping the working tree all the same except for the current change you're working on. All that's required is to register the file you want to change with an activity, change it and then build/test.

Unfortunately (well at least as i understood it) with pipeline etc, you could be working on one particular feature, then find you want to change part of a file for another feature/piece of work. This then requires a switch to the pipe you want this change to be registered with (meanwhile all other unrelated changes you have on the other pipe need to be updated/reverted in the working tree), change the file you want while you're on the correct pipe, pump it down to the final area, and then switch to the final pipe (which has all your changes combined and requires another update of files) to build the change with all the others. The additional context switches required to make sure your change gets registered on the correct pipe, in the pipeline is a bit of a drag and adds a bit of time overhead - especially if you want to avoid rebuilding a lot of work

I guess we have a special requirement because our codebase is large. So with this, changing contexts takes a bit of time, making sure you're in the right context to register the change you want to do take extra mental management, and making sure you're only building the working tree with all the changes together.

Based on what i've seen and what would probably help our workflow when using bazaar would be a feature where you could tag a commit of related files to a particular id or name and then be able to commit more changes in the future to the same id - .Then if you were able to view just the changes/commits of files committed with the id (ie being able to filter tangled unordered commits, as currently you really need to chronologically commit all work in order, or the second something is out of order that'll show up in your changset). This would be similar to the notion of acitvites/changesets of work and is a means of getting the revision snapshot model into a part changeset model (per set of related files). Whether such a thing is possible i am not too sure.

That, or even if the set of files you want to count as a set of changes and their start and end revision points, would work quite well for creating a diff set (of just those files) which would be easier to review. but also enables you to freely work on one branch and inter mix commits and changes for different features. Although if you changed the same file for 2 separate pieces of work it would show up in both review sets for those changes.

i hope those last 2 points help demonstrates part of the problem we want to try and solve when trying to adopt bazaar. And we'd still attempt to try out these solutions with other developers to see how they may want to work with the new tool (ie even though could be a long time to build things, task per branch does simplify a lot of these issues and reduce management of changes within a branch)

Thanks for any more input on my concerns

Cheers
Tom

I think being able to commit particular files to a particular other
branch would be useful. There may be a wishlist bug for it, if
there's not already feel free to file one.

--
Martin <http://launchpad.net/~mbp/>