Brian is absolutely right. I'm going to try and add something without starting a flame war.
This is the exact purpose that Git was designed for. While SVN can do branching and merging, it's slow and often a manual process. With Git, it's so fast that I often think that something broke. You mentioned that you do contrib work - D.O is migrating to git as well, so learning git now will have real value to you later. http://book.git-scm.com/ Git does have a learning curve to it, so if you don't have the time to pick it up, you can accomplish the same thing in SVN. It may leave a sour taste - I know it does for me. Justin On Wed, Apr 28, 2010 at 9:58 AM, Brian Vuyk <[email protected]> wrote: > Create branches for each specific task /feature you are trying to > implement. > > When a feature is implemented, merge that branch for it into the main > development branch. In the past, I've generally kept a 'production' branch > which mirrors what is on the production site. New features (each from their > own branch) are merged to that branch as they are completed, and tested > before production is updated from that branch. Finally, it helps to keep a > 'misc' branch for small tasks that may not require their own branch. > > It sounds like a lot of work, but it becomes second nature after a while. I > would suggest reading Chapter 4 of the SVN book: > http://svnbook.red-bean.com/en/1.1/ch04.html > > Brian > > > nan wich wrote: > > At my current location, I have developed a major site-specific module > (well over 100K). I have already split the admin, pages, and blocks out into > separate files. I have largely done this on the same model as I use for my > DO contribs. > > At any given time I may have four or five changes in place at various > stages of testing, and working on the next change. The problem is that the > powers-that-be occasionally want one change moved to production quickly. I > can't do that without potentially moving untested changes too. > > So I'm looking for ways that others get around this situation. Certainly I > can move various smaller pieces into include files; this is not a major > problem as we use eAccelerator to cache all the modules any way. Is that the > best way or only way? We do have SVN available. > > > *Nancy E. Wichmann, PMP* > > Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. > King, Jr. > > >
