Seriously, I would not create a branch for a bug, just to have it merged back to the trunk again.
You might as well apply the fix directly on the trunk... On 5/15/07, John Paul Ashenfelter <[EMAIL PROTECTED]> wrote: > > On 5/14/07, AJ Mercer <[EMAIL PROTECTED]> wrote: > > I am still not quite sure how to go about deploying mods from > subversion. > > This is what I am trying to achieve: > > > > Each developer has a local development environment. > > We have a job tracking systems (jira) that bugs and requests for new > > features are entered into. > > > > I will work on a bug and once I am happy with the fix, testing in my dev > > environment, I will put those changes onto the test server. > > We're missing some details here about the process around subversion so > it's hard to directly answer the question, but one very common pattern > is to create a bug-specific branch (usually off of the release branch) > and fix the bug there. The full process would work something like > this: > > * assume there's an existing branch for the release, /repo/branches/RB-1.0 > * copy the release branch /repo/branches/RB-1.0 to a bugfix branch > /repo/branches/BUG-3456 > * tag the beginning of the bugfix branch /repo/tags/PRE-3456 > * work on bug in the bugfix branch committing as necessary > * tag as necessary on bugfix branch, eg /repo/tags/QA-3456, > /repo/tags/QA-3456-RC2, etc > * when the bug's signed off on, tag the end of the branch > /repo/tags/POST-3456 > * back in the release branch, /repo/branches/RB-1.0, you can merge > /tags/PRE-3456 and /tags/POST-3456 to get the release updated > * roll out a new release (tagged and/or branched of course) or > generate a patchfile depending on your process > * check and see if the merge needs to go back into trunk/etc as > appropriate > > Obviously this isn't strictly necessary for a typo or a very small > change, though at a minimum using the tags for PRE and POST will make > your life easier. > > As an aside, Subversion revision numbers are not in short supply -- > there's no need to conserve them, and since copies in SVN are > efficient, there's no worry about increasing the size of the repo > every time you branch (like in BitKeeper and some other source control > systems). > > We'll cover this stuff in my CFUnited 2007 pre conference class. At > worst, if you're reading this and figuring you need to know more about > Subversion, you should check out the Pragmatic Version Control using > Subversion book from the Pragmatic Programmers and save yourself a lot > of effort in learning SVN. > > > After user testing, it may come back for further work, or be signed off. > > If signed off, it is put onto the production server. > > > > As you can imaging, there can be any number of bugs been fixed at any > point > > in time by multiple developers. > > The testing can get signed off in any order and may be there for a > couple of > > weeks. > > > > What I would like to be able to do is get the files for a particular bug > fix > > and from those file, merge the modifications into test and then > production. > > > > General Notes: > > > > - One file may have multiple bug fixes / enhancements > > > > - if a modification is to be backed out, and other modification since > then > > will need to stay. > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Upgrade to Adobe ColdFusion MX7 Experience Flex 2 & MX7 integration & create powerful cross-platform RIAs http://www.adobe.com/products/coldfusion/flex2/?sdid=RVJQ Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:278115 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
