OK, irrespective of whether the trunk or branches are used how do you selectively chose what you want to deploy?
If I have 5 bug fixes on the go bug001 - bug005, and bug004 is signed off how would I use subversion to know which files need to be updated on production (without any of the work on bugs 1,2,3,5 going over)? On 5/15/07, Andrew Scott <[EMAIL PROTECTED]> wrote: > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Deploy Web Applications Quickly across the enterprise with ColdFusion MX7 & Flex 2 Free Trial http://www.adobe.com/products/coldfusion/flex2/?sdid=RVJU Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:278120 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
