On 5/15/07, Andrew Scott <[EMAIL PROTECTED]> wrote: > Deploy? If you mean deploy to production, thats always trunk.
That's actually a really bad process in general -- b/c then you have to keep track of revision numbers to be able to revert to a previous release. The standard advice is to tag the trunk (eg REL-20070515 or REL-1.2.3) and then deploy the tagged release, which means exporting from the tag instead of trunk. That gives you a MUCH better history over time. Deploying from /trunk directly is generally a good way to handle continuous integration, but I recommend not doing that for production. Tagging gives the added benefit of repeatability without needing to track revision numbers, though clearly nothing stops you from doing it this way :) > Or do you mean deploy from your code to the repository, that's commit. > > On 5/15/07, AJ Mercer <[EMAIL PROTECTED]> wrote: > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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:278149 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
