On 08.08.2009 00:22, Stefan Fuhrmann wrote:
> Hi Stefan,
> 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'.
Well, I try to review any changes. I don't do it for every commit though.
>> 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
> on /trunk.
Agreed. Good suggestion!
>> 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.
Backward compatibility isn't a big deal for the log cache IMHO. Just
merge it back and have it tested by those using the nightly build.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-08-08 14:41:15 CEST