pbranches style plugin

[Robert Collins]

On Mon, 2009-06-01 at 15:12 +0100, Adrian Wilkins wrote:
> So, I looked at bzr-loom.

Cool. 

I think what users really want is darcs :). And I have some thoughts
about that that I will put in a separate mail, I think.

> 
> My initial frustration with loom is that it only helps you if you are 
> managing one stack of patches. Each thread in the loom by necessity 
> depends on the threads beneath it. To me, this doesn't make it any 
> easier to maintain patches - I want to be able to take a known revision, 
> and branch it, and maintain a set - not a stack - of patches on top of 
> it. If I write a patch that's dependent on one or more of the others, 
> fine. But most of them are not.

Loom was designed for people wanting to 
a) take some trunk and build some other trunk-like [long lived, needs to
have all of trunk in it, may have users] branch from it. With each
change clearly identified and able to be later backed out or
incorporated into the original trunk.
b) collaborate on this object with other developers.


> Example (real world) :
> 
> I am maintaining a project which is hosted across multiple SVN 
> repositories. The project owner also has his own particular environment 
> in which he has access to a Maven repository that I do not. I want to be 
> able to
> 
>   * Branch the repository branches (which I've done, using bzr-svn)
>   * Patch the Maven pom.xml files so they use versions of the projects 
> for which I have the source, because I can build those, rather than 
> older versions, which are in the private repository.
>   * Fix bugs
>   * Make changes
> 
> Of these, I'd like to be able to push my bug fixes back to the 
> subversion repository, but I don't want to push my changes to pom.xml files.

When taking changes from a loom and pushing them back upstream, use
cherrypick merges. Why? Because loom simplifies the problem by using a
stack rather than a graph, threads are not necessarily adjacent to
upstream. It should always be as simple as:
bzr switch thread-to-merge
cd $upstream
bzr merge $loom -r thread:..-1
bzr commit

> My style of working is heavily informed by the Old Ways, and thus making 
> feature branches is not second-nature to me yet, but even if it was, 
> this would be lots of work.
> 
> I had a look at the beta Mercurial pbranches [1], and this seemed more 
> like what I needed than loom.
> 
> What would be really nice is a UI that will let you choose, down to a 
> per-hunk basis if possible, which bits of your commit go in which patch 
> branch, and do branch management. You continue to work in your work 
> branch, which is a merge of all the various threads beneath it. When you 
> commit, you mark each file or hunk to determine where it goes (and maybe 
> provide a comment for each target branch).

This is something loom wants to, and is [IMO] totally unrelated to
whether a graph or stack of feature branches is maintained.

Commit is getting very close to being able to do what I'd like it to
here, quickly and simply. Its not quite there yet.

-Rob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090605/9dc9d8f1/attachment.pgp