Hi Philipp,
We use trunk as a stable stream.
All work, feature or bug fix are performed on a branch.
We merge back to trunk any changes that are ready for release. We also
use trunk to propagate changes to all development teams.
If you follow the above practise, then in your case, the bug fix i
On Wed, Feb 17, 2010 at 11:18 AM, Philipp Leusmann <
philipp.leusm...@rwth-aachen.de> wrote:
>
> Am 17.02.2010 um 16:46 schrieb Rob van Oostrum:
>
> On Wed, Feb 17, 2010 at 9:09 AM, Philipp Leusmann <
> philipp.leusm...@rwth-aachen.de> wrote:
>
>> Thank for you hint, Bob, but I have doubts this wa
Am 17.02.2010 um 16:46 schrieb Rob van Oostrum:
> On Wed, Feb 17, 2010 at 9:09 AM, Philipp Leusmann
> wrote:
> Thank for you hint, Bob, but I have doubts this way a merging works out for
> us, since we are working in a small team without "voting" each task. So, I
> have the fear, that changes
On Wed, Feb 17, 2010 at 9:09 AM, Philipp Leusmann <
philipp.leusm...@rwth-aachen.de> wrote:
> Thank for you hint, Bob, but I have doubts this way a merging works out for
> us, since we are working in a small team without "voting" each task. So, I
> have the fear, that changesets committed to trunk
Thank for you hint, Bob, but I have doubts this way a merging works out for us,
since we are working in a small team without "voting" each task. So, I have the
fear, that changesets committed to trunk contain unrelated changes, which by
accident make it into the branch.
So, it would be nice to
> Hi all,
>
> we are currently rethinking our svn branching strategy and one question
> came up.
>
> To explain what we are planning to do:
>
> We are going to use a release-branching, with adding new features to
> /trunk .
> At some point in time, we will create a ReleaseCandidate-branch from t
