H. S. Teoh wrote:
> On Fri, Sep 24, 2004 at 03:34:31PM -0500, Sean Laurent wrote:
> [...]
>
>>A typical scenario we encountered follows:
>>
>>1) Install team generates Build #42 of product XYZ based on revision 1000 and
>>produces a label, associating XYZ_BUILD_42 with revision 1000.
>>2) Developers continue to make changes to the branch.
>>3) QA team reports a nasty, difficult bug in Build #42 that gets assigned to
>>me.
>>4) At this point, the repository is up to revision 1100. To simply my ability
>>to reproduce and track down the bug, I checkout XYZ_BUILD_42.
...
> You don't need to know any revision numbers. If you have tagged build
> 42 as /tags/xyz_build42, you could just do:
>
> svn co /tags/xyz_build42
>
> Job done. No revision numbers involved.
That's not the end of the problem. Somebody needs to be able to patch
that release, which means creating a branch off of this copy. How do
you maintain a branch graph this way? Suppose the same thing occurs
with build #45 at revision 1700, which means you now have two branches,
say patch001 and patch002. Then somebody comes along who can't remember
the history and needs to answer the question of which of these, if any,
contains the change that was made on the main development branch
somewhere between revisions 1450 and 1460? How do you answer questions
like that? How hard is it to manually create the branch graph in the
general case? What about automatically creating the branch tree --
keeping in mind that the copies on the /tags tree shouldn't appear in
the graph?
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Sep 27 04:12:00 2004