[development] Site specific modules

[Justin Ellison]

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 <brian at brianvuyk.com> 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20100428/10e22290/attachment-0001.html