[picocontainer-dev] RE: *** SPAM *** [8.2/6.0] Re: [picocontainer-dev] patches for *full* binding-annotation capability
Jörg Schaible <[email protected]>
| Newsgroups | gmane.comp.java.picocontainer.devel |
|---|---|
| Message-ID | <[email protected]> |
Paul Hammant wrote:
>> Paul Hammant wrote:
>>> I'd apply them of course, but Konstantin has a precarious branch he
>>> may want to merge back in the future <grin/>
>>
>> BTW: Why don't you run your own branch for this?
>>
>
> Not withstanding the fact that I'm guilty of the baby-steps branch,
> in the majority of cases, I don't approve of branches -
>
> http://paulhammant.com/blog/branch_by_abstraction.html
>
> I love getting an opportunity to plug that article :)
Well, we don't talk about 20 branches here. But Konstantin as well as you are "playing" with new functionality that will impact the trunk. With your changes on the branch, it would be much easier to have a look, propose changes and watch improvements. And when the branches are finished (i.e. merged or discareded), they should be deleted again (remember, svn still kows about them, but they are no longer visible, since invalid). Have a look at git and ask Jason, he is quite fond of it. It was especially made for a lot of individual branches, because in git *anything* is a branch.
> In this case, Konstantin has a potentially large change to merge
> back. If I applied my change to trunk first, it will be quite hard
> for him.
It does not matter. The work is always the same. If you merge back your changes first, he can merge all changes from your branch into his own. If he merges back first, you can do the same.
> He already has a moderate risk of not-completing his goal,
> it'll be worse if I go off in a divergent direction on trunk.
> If Konstantin is as respectful (he's a 'good egg') he'll take a look
> at the patch and suggest that its mergeable after his change, or
> before it, or accomotate the same changes in his branch (chasing the
> JasonsTestCase 'specification')
This task is much easier using the svn merge command as proposed above. That gives even the possibility of an incremental merge i.e. if Konstantin decides today to merge your branch, but cannot merge back into trunk yet, he still may take quite easily all additional changes until he is ready. With your single patch it is alway an all-or-nothing.
- Jörg
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email