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.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to