On 5/15/07, Andrew Scott <[EMAIL PROTECTED]> wrote: > 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...
Unless the trunk has diverged from the release -- this is all very dependent on how releases work. Let's say you fix a stylesheet element directly in trunk. That's fine if trunk hasn't changes since the release you're fixing; it's NOT fine if you upgraded from Fusebox 4 to Fusebox 5 during the intervening time or any other major changes that separate the ongoing trunk work from a release. It all depends on the process -- Subversion doesn't care one way or another :) But seriously, I'd always recommend tagging releases -- otherwise you end up using revision numbers to proxy for releases and that inevitably seems to cause problems in the long term. > 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. > > > > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| ColdFusion MX7 by Adobe® Dyncamically transform webcontent into Adobe PDF with new ColdFusion MX7. Free Trial. http://www.adobe.com/products/coldfusion?sdid=RVJV Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:278147 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
