<br><br><div><span class="gmail_quote">On 12/13/06, <b class="gmail_sendername">Larry Garfield</b> <<a href="mailto:larry@garfieldtech.com">larry@garfieldtech.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>My company is not a Drupal shop primarily (this is our first Drupal site), and<br>we don't have CVS at work (just SVN), so what I've been doing for patches is<br>making an issue with some notes in it on the appropriate project, then when I
<br>get home (or a day or three later) rolling the patch at home myself and<br>submitting that. Then I just tell the client "here's this issue, be<br>careful". So far it hasn't caused any major catastrophes, but then they've
<br>all been fairly minor changes. I'm rather curious how more active<br>consultant/developers handle it.<br></blockquote></div><br>That's pretty much good best practices. We use Trac on top of SVN and file tickets that point to Drupal issues and follow up with them to make sure that the patch (or a version of it) gets in, and then synching the deployed code with the patch included.
<br><br>There are some other issues around branching/tagging that you have to figure out a process for in terms of rolling out updates, as well as scheduling "upstream syncing" with contrib modules you are using, but, as I said, this is mostly process and procedure. I want to do some more thinking and perhaps a writeup on the SVN / CVS combo and approaches to branching for different kinds of projects.
<br><br>All of this is classic change management stuff. With Drupal and open source in general, you "pay" in doing this kind of change management rather than official vendor fixes (or not being able to do ANY fixes until you scream at a vendor enough).
<br clear="all"><br>-- <br>Boris Mann<br>Vancouver 778-896-2747<br>San Francisco 415-367-3595<br>Skype borismann<br><a href="http://www.bryght.com">http://www.bryght.com</a>