Questions about Bundle Buggy

[Russ Brown]

John Arbash Meinel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Russ Brown wrote:
> | Thank you both for your replies.
> |
> | Aaron Bentley wrote:
> | Russ Brown wrote:
> |>>>  3. Is it capable of dealing with more than one project 
> (repository) at
> |>>> once? For example, if our system comprise of several separate 
> codebases,
> |>>> each in their own shared repository (with multiple branches), can the
> |>>> one BB installation deal with that?
> |
> | Bundle Buggy does not support multiple projects at the moment, but that
> | is a feature I hope to introduce.
> |
> |
> |> That would be fantastic. We're on the verge of migrating and need to
> |> make decisions about how to structure the code we have (which is
> |> currently in one monolithic subversion repository). My preference is to
> |> break it logically but we only want to do that if the tools are will be
> |> using (hopefully including BB) support it.
> |
> |> Then again, I suppose we could start with one repository and then split
> |> it up later as the tools support it.
> 
> It is generally better to start split and join things together. Just 
> because of
> the size of history issues. When you split a project in bzr, it still 
> references
> the full history (unless you regenerate the whole branch, at which time 
> it is
> incompatible with your other work.)
> 

Regeneration wouldn't be a problem when wanting to split. For some 
context, I'm dealing with what was originally a CVS repository, which 
the company put *everything* as top-level modules. Many of these modules 
are completely unrelated to each other, and ideally I would like them to 
live in separate repositories. But for simplicity I think I'm leaning 
towards migrating them as is and splitting them out later.

> 
> |
> |
> |>>>  4. Can it handle requests to merge to multiple branches within the 
> same
> |>>> repository?
> |
> |> (From John's reply:)
> |
> |>  > BB only tracks patches to be merged. I believe it has to be set up as
> |>  > 1 queue per destination branch.
> |
> |> So does this mean if a new branch is created, there needs to be a manual
> |> action taken to 'register' the branch in BB? We're not sure yet if we'll
> |> be using BB to only handle the review of commits to mainline, or if our
> |> developers will need to get review on all branches. The answer to this
> |> question would likely have some bearing what we do there.
> 
> BB is designed to track merges into 1 target. Such that it can tell when 
> things
> have and have not been merged there. (Automatically setting the "Merged" 
> flag,
> and clearing it out of the queue.)
> 
> I believe it would let you send patches for other branches, and just 
> require you
> to manually hit the "Already Merged" button.
> 

I think I'm basically going to need to get my hands dirty and have a 
play. :)

Thanks again.

> John
> =:->
> 
> |
> |>>>  5. Has anyone considered writing a Trac plugin that integrates BB 
> into
> |>>> trac? If not does anyone foresee any problems with such a project? It
> |>>> would be nice to have everything under 'one roof'.
> |
> | I can't imagine that working very well, since BB and Trac have different
> | web frameworks.
> |
> |
> |> That's a shame: it would be nice to be able to integrate them since they
> |> don't seem to overlap at all and yet compliment each other nicely.
> |
> |>>> Apologies if these questions are answered elsewhere: I couldn't find
> |>>> them, and I don't have time to experiment (play!) right now. :(
> |
> | There is a web site for Bundle Buggy here:
> |
> | http://code.aaronbentley.com/bundlebuggy/
> |
> | It's not especially well advertised, and I apologise for that.
> |
> |
> |> Ah, thanks. I hadn't found this.
> |
> |> For what it's worth, I recommend that you do advertise BB and shout
> |> about it a bit more: it's an excellent bit of work. :)
> |
> |> (Note that allowing integration into other tools such as trac would be
> |> an easy way to increase exposure... Just a thought!)
> |
> | Aaron
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Cygwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkgkcV8ACgkQJdeBCYSNAANtuQCgkvqOu9qWonol28BQ0Xjp0OTS
> D34AoLk6oT59YBuM2LFTLjzemQhPNAe/
> =o3dz
> -----END PGP SIGNATURE-----