Stefan Küng wrote:
>You have the habit of creating a new branch for every task you want to
>do. While that's of course allowed, I'd rather have you working on
>trunk. Otherwise it's way too much to review when you finally merge your
>branches back to trunk.
I was not aware that you review my changes in detail.
Since I really appreciate any feedback, I'm more than
happy with shifting my branching bias more towards
'working on trunk'.
>If you would work on trunk, I could review your changes in smaller
>chunks, and you'd have the benefit of lots of people testing your changes.
The reason why I do most non-trivial off-trunk is that
I didn't want to break the respective features for
several days. If you think that this policy does more
harm than good, let's change it.
How about the following:
* Smaller stuff happens on trunk w/o further notice.
Build and functionality may occasionally break but
fixes should be in place within a week.
Example: My current repo browser work.
* Larger work that will destabilize central functionality
over a longer but foreseeable period (up to a month)
will also happen on trunk. Previous notice on dev@
is required, though.
Example: Refactoring the log dialog code.
* Large and / or blocking work shall be done on branches.
Theoretical Example: Replacing the build system.
If something gets out of hand, we can still opt for
branching off + temporarily undoing the changes
>Is the branch for the repo browser changes really necessary?
No. And since it is mainly working again, I merged
the changes back to /trunk and will finish the work
Finally, speaking of branches, I would like to merge
the remaining patches from the 'Performance'
branch into /trunk. Their only drawback is that
log caches are no longer backward compatible,
i.e. older versions will discard them automatically.
After the merge, I would close that branch as well.
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-08-08 00:22:26 CEST