lol... Previous discussions showed there was many ways to skin the cat, this will not only be that but many ways to cook it as well.
This is really one asspect that is going to be what works best for you. But when developing in situations like this, it is going to be a case of create diff patches or manage it with merges. Either way it is going to take strong discipline on this. My method is to sync the code as the bug is completed, and ready for testing but here is the best approach that we adhere too. before commiting any code, sync with the repository have any changes been made to the code while you had it. Yes, then merge those changes with your code and the re test the code that was fixed with unit tests as a prefered method would identify any problem very early. But if that is not applicable then the developer will need to run any change that will effect what he/she has written. This is so that the bug / enhancement or whatever is proven to be fixed. then you can submit the code as being stable back to the repository. Now the one thing I will stress... At this point, the process of sync / merging code can take a few goes at it. So the developer will need to be aware of this, and the idea of sync the code at this level is that the developer should be the one to know if any of the changes prior to his will effect his code or not and maybe he/she needs to make changes due to the changes not being know at that time. Small note, this is why methods of locking can be benficial but it can impeed teams of developers from doing their work in a timely fashion, hope that makes sense. So after a few goes at this, the developer can then merge his/her code with the repository or commit fully. The point to recall when mergin / diffing the developer also should at least do an update on that file as well to make sure they have the lates on their end if they plan to keep their code up to date. As you can see, this is a complicate issue and it will as mentioned boil down to what best suits you or how it can be adopted with changes to your process. So I can only comment on what I have understood from the manual to get this method / understanding, and why it will take a huge discipline with your developers. 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. > > 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 and Flex 2 Build sales & marketing dashboard RIAâs for your business. Upgrade now http://www.adobe.com/products/coldfusion/flex2?sdid=RVJT Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:278002 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
