AJ, Welcome to the world of many ways to skin a cat.
We do it the same way I outlined a few times now, but others have diffeent ways to do it. When working on something that is either new or a bug, the code is looked at and fixed now until it is fixed, tested with unit tests and the development tested we do not commit it back to SVN. Thats our procedure, but as I said earlier, we also sync the changes to make sure we don't need to merge any new code, and then when its tested, merged on our code with the repository we then commit it. Thats our method, and others have many other ways of doing it. On 5/15/07, AJ Mercer <[EMAIL PROTECTED]> wrote: > > If by bug you mean typo or something minor - then making the change to the > trunk would seem fine. > > I am think more along the lines where 2 or more pages need to be modified > and may span a number of days (elapsed time) > > > When it comes to committing , would it be fair to say:- > trunk: only commit logical units of work that will not break the system > branch : knock yourself out > > > With so many different views and recommendation it is no wonder I am > getting > confused :-} > > 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... > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Macromedia ColdFusion MX7 Upgrade to MX7 & experience time-saving features, more productivity. http://www.adobe.com/products/coldfusion?sdid=RVJW Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:278119 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
