Recommendation for how to handle workspace with "processing" contributions
Locked
Recommendation for how to handle workspace with "processing" contributions
 
|
Re: Recommendation for how to handle workspace with "processing" contributions
|
|
I've always kept a clean ofbiz-trunk with changes in them - which is
where I create the patches from. Then in the individual projects that I'm working on, I maintain a set of patches that I must apply to the framework/applications area at least until the trunk gets updated with my patches. Then I've got the best of both worlds - the separate download where I maintain and build my patches as well as my project specific place where I wouldn't be creating my patches from. Hope that helps - and if you have any other questions on exceptions to this rule, please feel free to ask some more Q's. Cheers, Tim -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6595 On Jul 31, 2009, at 4:47 PM, Bob Morley wrote: > > While I have been working on Ofbiz for a while, I have not made a > good enough > effort to contribute back bug fixes and enhancements that I feel > would be > valuable to the product. I have started to do this, but I have a > question > about how people handle their workspace while they are waiting for > contributions to be approved/rejected. > > I have created a few JIRAs and attached patch files to them for my > changes. > However, as I do more and more work I end up with more and more > changes in > my workspace that are updated. It will ultimately become very > difficult to > determine which files I should include in the next patch; moreover I > may > result in dependencies. > > Does any non-contributor (or contributor for that matter) have a > suggestion > on how to manage this? I am thinking about using Mylyn and the JIRA > integration to relate the files. This does not help the patch > generation > ... > > Anyone have a better suggestion? > -- > View this message in context: http://www.nabble.com/Recommendation-for-how-to-handle-workspace-with-%22processing%22-contributions-tp24764099p24764099.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. > |
smime.p7s (3K)
Re: Recommendation for how to handle workspace with "processing" contributions
|
|
Re: Recommendation for how to handle workspace with "processing" contributions
|
|
Yeah - I totally feel you on that. What I do is remove the changed
files from that ofbiz-trunk and put them back to the trunk versions while I'm working on a different set of code. The only time that you get in a real pickle is when you have multiple commits that cross files and at that point - it's difficult no matter what you do. The ideas that you're bringing to the community all seem pretty sound, so my guess is that you won't have too much resistance making the changes and then getting them into the project. Since you're doing most of your testing on your project specific code bases - those are the ones where the patches and how they interrelate, becomes the most important. Anyways, not sure if that was helpful, but that's how I keep it clean. That being said, I'm not nearly as active coding as I have been in the past, so guys like David, Andrew, Anil, Jacopo, Scott, Adam, Hans, Ashish, Vikas, etc may be able to shed a bit more light on the subject than I can at the moment. Cheers, Tim -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6595 On Jul 31, 2009, at 5:20 PM, Bob Morley wrote: > > Hey Tim -- I have a question about the first sentence ... as you get > more and > more changes built up does it not become more difficult to create new > patches? Unless there is a better way I have been doing an "svn diff > [change-list] > patch.diff". The trouble is as I get more and more > files in > my total change set, it becomes more difficult to determine which > ones are > in my specific patch. :) > > > Tim Ruppert wrote: >> >> I've always kept a clean ofbiz-trunk with changes in them - which is >> where I create the patches from. Then in the individual projects >> that >> > > -- > View this message in context: http://www.nabble.com/Recommendation-for-how-to-handle-workspace-with-%22processing%22-contributions-tp24764099p24764365.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. > |
Re: Recommendation for how to handle workspace with "processing" contributions
|
|
Re: Recommendation for how to handle workspace with "processing" contributions
|
|
Re: Recommendation for how to handle workspace with "processing" contributions
|
|
Re: Recommendation for how to handle workspace with "processing" contributions
|
|
Good luck with that. I used to be the vendor branch guy - and after a
while it just didn't work out very well. Also, deletes are not so good with the tools that are available out of the box. If you get a strategy that works, I'm always interested in hearing how as this was a tough one ... Cheers, Tim -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6595 On Aug 1, 2009, at 10:09 AM, Vince Clark wrote: > Thanks BJ. I didn't realize that link was out there. > > I recently set up vendor branch management for our company and > generally like using that approach. The only issue I have with it is > that I haven't really found a good way to "selectively merge" the > differences between revs. One of the main reasons for doing this is > so you aren't tied to trunk and therefore can (theoretically) > maintain a stable copy of the code. But when you do the merge you > get all the changes. Obviously you still have control in the sense > that you can test it before you deploy the new version. But some > changes you may never want to accept, for example changes to the UI. > > Any idea how to review and select what changes get merged? > > > Vince Clark > www.globalera.com > [hidden email] > (303) 493-6723 office > (303) 523-4843 cell > > > ----- Original Message ----- > From: "BJ Freeman" <[hidden email]> > To: [hidden email] > Sent: Saturday, August 1, 2009 7:10:48 AM GMT -07:00 US/Canada > Mountain > Subject: Re: Recommendation for how to handle workspace with > "processing" contributions > > opps > http://docs.ofbiz.org/display/OFBIZ/SVN+Tips+-+svn_load_dirs+Vendor+Branch > > BJ Freeman sent the following on 7/31/2009 5:24 PM: >> take a look at this >> also name your patches for the jira number and component or file it >> effects. that way it is easy to update them. >> >> Bob Morley sent the following on 7/31/2009 3:47 PM: >>> While I have been working on Ofbiz for a while, I have not made a >>> good enough >>> effort to contribute back bug fixes and enhancements that I feel >>> would be >>> valuable to the product. I have started to do this, but I have a >>> question >>> about how people handle their workspace while they are waiting for >>> contributions to be approved/rejected. >>> >>> I have created a few JIRAs and attached patch files to them for my >>> changes. >>> However, as I do more and more work I end up with more and more >>> changes in >>> my workspace that are updated. It will ultimately become very >>> difficult to >>> determine which files I should include in the next patch; moreover >>> I may >>> result in dependencies. >>> >>> Does any non-contributor (or contributor for that matter) have a >>> suggestion >>> on how to manage this? I am thinking about using Mylyn and the JIRA >>> integration to relate the files. This does not help the patch >>> generation >>> ... >>> >>> Anyone have a better suggestion? >> > > -- > BJ Freeman > http://www.businessesnetwork.com/automation > http://bjfreeman.elance.com > http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro > Systems Integrator. > |
| Free forum by Nabble | Edit this page |