Irvine, Chuck R [EQ] wrote:
>
> [snip]
>> Irvine, Chuck R [EQ] wrote:
>>> We have very well defined requirements for each release. And if we
>>> adopt this branching scheme, we will have in our repository
>>>
>>> Repo/application/
>>> release1/
>>> release2/
>>> release3/
>>> ...
>>>
>>> So developers are very clear where they should be working.
>> And once a
>>> release dir (branch) is created the development for that release
>>> always stays on the same branch (and doesn't at some point
>> jump to a
>>> release branch).
>>>
>>> Yes, R1 changes have to get propagated to R2, R2 to R3, etc. We do
>>> this my merging R1 -> R2 -> R3, etc.
>> Doesn't that lose a lot of the development history log
>> compared to doing
>> all pre-release work that doesn't absolutely have to isolate your
>> developers on the trunk and branching only when it is time to
>> stabilize
>> the releases?
>
> I don't know what is meant by "losing development history log". You can
> always look at the history of the top level "application" directory.
If you look at a file in the 'release3' branch, can you see all the
individual commits in its history with useful comments as you would if
you did all the work in the trunk and viewed from there or just a bunch
of 'merged from' aggregates for the changes done elsewhere?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 27 23:33:33 2007