Reinhard Brandstaedter wrote:
>> The alternative is to use branches as change sets and merge from the
>> branches to get the features and fixes you need for a release. I don't
>>
>> like committing changes directly on the trunk (which is what complex
>> tags encourages).
>>
>> The bookkeeping for complex tags breaks down when you have to perform
>> multiple commits for a single change. For example, I fix bug A,
>>
> commit,
>
>> then add feature X and commit. Now, I find the fix to bug A still has
>>
> an
>
>> issue. So, I make more changes and commit. With complex tags, I would
>>
> be
>
>> unable to easily select only the bug A fix for a release; I would have
>>
>> to check out the latest fix and then reverse delta the feature X
>>
> change.
>
>> I also no longer have a way to easily tell what changes were made to
>>
> fix
>
>> bug A.
>>
>
> This implies that you use one branch for every new feature (you could
> also use one branch for multiple features) and a branch for bugfixes
> which makes it easy to merge features and bugfixes easily between
> branches.
> A good approach in my opinion, but it really depends on the development
> process and how "big" (or how long they depend to develop) new features
> are. Meaning: when opening a new branch for a feature? when it takes 2
> days to develop it? A week? A month? This decision has to be made
> somehow and of course accordingly to the piece of software the team is
> writing.
>
> Reinhard
>
>
Yes this is indeed what I was implying. We have some simple guidelines
for when you have to create a branch. For example, if the change takes
more than one commit or if you change an exposed API, it goes on a
branch. We allow developers to change the trunk directly when the risk
is low.
-- John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 20 15:01:12 2006