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.
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@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.
Yes, I do contribs (20+). But, as I am sure Derek would testify, that doesn't mean I know CVS. Nor do I know SVN. I am an inveterate GUI user. Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr. ________________________________ From: Justin Ellison justin@techadvise.com 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.
I completely agree with Justin, and can't recommend Git enough. Especially when a lot of different features are developed at the same time. And it's very easy to check how different features work together by creating new branch and than merging features in it. It's so fast and easy, that I wonder how I ever coded without it... On Wed, 2010-04-28 at 10:16 -0500, Justin Ellison wrote:
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.
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@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. > >
-- Nikola Kotur http://nultibitovi.net
On Apr 29, 2010, at 8:42 AM, Nikola Kotur wrote:
I completely agree with Justin, and can't recommend Git enough.
Especially when a lot of different features are developed at the same time. And it's very easy to check how different features work together by creating new branch and than merging features in it. It's so fast and easy, that I wonder how I ever coded without it...
I would love to hear some tips on managing changes to the database with git. I'm comfortable with git and use it in my Ruby on Rails work, so I've been using it for my Drupal work, too. When I'm working on a site, it's easy to dump my dev database and push it up to my production server, then simply replace the production database. What do you do for a live site, though? How can I merge new work on modules and their configurations in my dev database up to the production site? Lisa Lisa Sawin lisa@lisasawin.com www.wintersondesign.com 203.209.2408
On 29/04/10 14:52, Lisa Sawin wrote:
I would love to hear some tips on managing changes to the database with git. I'm comfortable with git and use it in my Ruby on Rails work, so I've been using it for my Drupal work, too. When I'm working on a site, it's easy to dump my dev database and push it up to my production server, then simply replace the production database. What do you do for a live site, though? How can I merge new work on modules and their configurations in my dev database up to the production site?
Not so much the database generally as specifically getting the configurations, settings and variables out of the database and into the code with minimal pain (and only a little bit of getting a used to the workflow):- http://drupal.org/project/features http://drupal.org/project/strongarm ekes
On Thu, 2010-04-29 at 08:52 -0400, Lisa Sawin wrote:
What do you do for a live site, though? How can I merge new work on modules and their configurations in my dev database up to the production site?
Unfortunately I haven't figured out that one yet, and if someone did, I'd be more than happy to read the explanation. I just setup reasonable defaults, and than configure/reconfigure module on production site after code deployment. -- Nikola Kotur http://nultibitovi.net
If it's a pretty big update then I usually roll out an update module. To help track the differences I use MySQL Diff on the needed tables, then go through and figure out what should stay and what should go. If it's a really big update, then I run a command line script to do a lot of the changes. I'm getting ready to roll one of these out for a client in the next couple of weeks and the amount of changes going in will blow your mind. It takes my CLI script about an hour to run and update everything, which includes a bunch of grepping on the 40,000 nodes and updating them. Jamie Holly http://www.intoxination.net http://www.hollyit.net On 4/29/2010 9:33 AM, Nikola Kotur wrote:
I just setup reasonable defaults, and than configure/reconfigure module on production site after code deployment.
With d.o moving to git, I'm becoming more interested in how it works. Can anyone point me to a really solid primer? I've looked around at length and am having a tough time grokking how git works, especially in regards to multi-person development. For example, I have one project that the previous dev set up to use git. For just me that's fine -- git add, git commit -a, git push, then reset to head on the dev server. But when more than one person is involved all hell breaks loose: Say you and I edit the same .css file and for some reason there's a conflict (git seems very bad at merging .css compared to svn from my experience). In svn: svn ci, see you're out of date, svn up, resolve the conflict, svn resolved, svn ci, done. In git this is all confusing and you can even break MERGE_HEAD if you try to git pull after resolving a conflict and git will think you still have conflicts to resolve. It's all very troublesome. From what I can tell, this is a common confusion coming from a "commit-update"-style system like svn; regardless, I still don't really get it. Any tips/articles/anything? Thanks, -D
For Drupal: Pro Drupal Development For Git: Pro Git - http://progit.org/ Victor Kane http://awebfactory.com.ar http://projectflowandtracker.com On Thu, Apr 29, 2010 at 6:34 PM, Domenic Santangelo <domenics@gmail.com>wrote:
With d.o moving to git, I'm becoming more interested in how it works. Can anyone point me to a really solid primer? I've looked around at length and am having a tough time grokking how git works, especially in regards to multi-person development.
For example, I have one project that the previous dev set up to use git. For just me that's fine -- git add, git commit -a, git push, then reset to head on the dev server. But when more than one person is involved all hell breaks loose:
Say you and I edit the same .css file and for some reason there's a conflict (git seems very bad at merging .css compared to svn from my experience). In svn: svn ci, see you're out of date, svn up, resolve the conflict, svn resolved, svn ci, done. In git this is all confusing and you can even break MERGE_HEAD if you try to git pull after resolving a conflict and git will think you still have conflicts to resolve. It's all very troublesome.
From what I can tell, this is a common confusion coming from a "commit-update"-style system like svn; regardless, I still don't really get it. Any tips/articles/anything?
Thanks, -D
http://whygitisbetterthanx.com/ -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci
Here are the most relevant sections from the documentation mentioned here yesterday: http://book.git-scm.com/3_basic_branching_and_merging.html http://book.git-scm.com/3_distributed_workflows.html All the Best, Matt Chapman Ninjitsu Web Development -- The contents of this message should be assumed to be Confidential, and may not be disclosed without permission of the sender. On Thu, Apr 29, 2010 at 2:34 PM, Domenic Santangelo <domenics@gmail.com> wrote:
With d.o moving to git, I'm becoming more interested in how it works. Can anyone point me to a really solid primer? I've looked around at length and am having a tough time grokking how git works, especially in regards to multi-person development.
For example, I have one project that the previous dev set up to use git. For just me that's fine -- git add, git commit -a, git push, then reset to head on the dev server. But when more than one person is involved all hell breaks loose:
Say you and I edit the same .css file and for some reason there's a conflict (git seems very bad at merging .css compared to svn from my experience). In svn: svn ci, see you're out of date, svn up, resolve the conflict, svn resolved, svn ci, done. In git this is all confusing and you can even break MERGE_HEAD if you try to git pull after resolving a conflict and git will think you still have conflicts to resolve. It's all very troublesome.
From what I can tell, this is a common confusion coming from a "commit-update"-style system like svn; regardless, I still don't really get it. Any tips/articles/anything?
Thanks, -D
To add to the resources: Git Screencasts (not updated anymore, but useful) - http://www.gitcasts.com <http://www.gitcasts.com/>Git Ready - http://www.gitready.com/ <http://www.gitready.com/>Cheers ---------------------------------- Dipen Chaudhary Founder, QED42 : We build beautiful and scalable web strategies ( www.qed42.com ) Blog: dipenchaudhary.com Twitter: http://twitter.com/dipench On Fri, Apr 30, 2010 at 3:12 AM, Matt Chapman <matt@ninjitsuweb.com> wrote:
Here are the most relevant sections from the documentation mentioned here yesterday:
http://book.git-scm.com/3_basic_branching_and_merging.html http://book.git-scm.com/3_distributed_workflows.html
All the Best,
Matt Chapman Ninjitsu Web Development
-- The contents of this message should be assumed to be Confidential, and may not be disclosed without permission of the sender.
On Thu, Apr 29, 2010 at 2:34 PM, Domenic Santangelo <domenics@gmail.com> wrote:
With d.o moving to git, I'm becoming more interested in how it works. Can anyone point me to a really solid primer? I've looked around at length and am having a tough time grokking how git works, especially in regards to multi-person development.
For example, I have one project that the previous dev set up to use git. For just me that's fine -- git add, git commit -a, git push, then reset to head on the dev server. But when more than one person is involved all hell breaks loose:
Say you and I edit the same .css file and for some reason there's a conflict (git seems very bad at merging .css compared to svn from my experience). In svn: svn ci, see you're out of date, svn up, resolve the conflict, svn resolved, svn ci, done. In git this is all confusing and you can even break MERGE_HEAD if you try to git pull after resolving a conflict and git will think you still have conflicts to resolve. It's all very troublesome.
From what I can tell, this is a common confusion coming from a "commit-update"-style system like svn; regardless, I still don't really get it. Any tips/articles/anything?
Thanks, -D
On 29 Abr 2010 22h34 WEST, domenics@gmail.com wrote: Here are the slides in PDF of a presentation Scott Chacon, who runs the git-scm.com site and is the author of Pro Git, gave somewhere in France recently. http://www.slideshare.net/chacon/git-101-presentation From what I can tell it's an expanded version of a talk he gave at Pivotal Labs last year. Here's the video: http://pivotallabs.com/talks/80-git-for-newbies HTH, António --- appa
Excellent video, thanks! Knew much of it, but so helpful to have a talk-through of the various features. Laura On Apr 29, 2010, at Thu 4/29/10 4:01pm, Antonio P. P. Almeida wrote:
On 29 Abr 2010 22h34 WEST, domenics@gmail.com wrote:
Here are the slides in PDF of a presentation Scott Chacon, who runs the git-scm.com site and is the author of Pro Git, gave somewhere in France recently.
http://www.slideshare.net/chacon/git-101-presentation
From what I can tell it's an expanded version of a talk he gave at Pivotal Labs last year. Here's the video:
http://pivotallabs.com/talks/80-git-for-newbies
HTH, António --- appa
On 2010-04-29, at 5:34 PM, Domenic Santangelo wrote:
With d.o moving to git, I'm becoming more interested in how it works.
On a related topic, anyone using git in a way like how subversion does vendor branches? Currently I do a cvs export => svn with svn_load_dirs.pl, and I'd be really interested on any resources on how to best do this with core and contrib code. --Andrew
On 30 Abr 2010 02h12 WEST, andrewberry@sentex.net wrote:
On 2010-04-29, at 5:34 PM, Domenic Santangelo wrote:
With d.o moving to git, I'm becoming more interested in how it works.
On a related topic, anyone using git in a way like how subversion does vendor branches? Currently I do a cvs export => svn with svn_load_dirs.pl, and I'd be really interested on any resources on how to best do this with core and contrib code.
Well I'm pretty much ignorant in SVN terminology but in Git, a branch is just a pointer to a given commit. So you can branch as much as you want. git checkout -b my_new_branch [old_branch] Now you're on my_new_branch that was created from old_branch. Work on it. The old_branch default is HEAD. git checkout old_branch You're back on old_branch. That's it. Git always copies all files that change in a given commit. It doesn't keep deltas like others SCMs. --- appa
In terms of svn-like vendor branches, there are many tricks around the web, but the most intelligent discussion I have found is in Chapter 6 of Pro Git, in the discussion of submodules, superproject (a small pithy paragraph which I think touches on the Drupal case) and subtrees. It remains to be seen what will emerge as the "Drupal way" here... Victor Kane On Thu, Apr 29, 2010 at 10:27 PM, Antonio P. P. Almeida <perusio@gmail.com>wrote:
On 30 Abr 2010 02h12 WEST, andrewberry@sentex.net wrote:
On 2010-04-29, at 5:34 PM, Domenic Santangelo wrote:
With d.o moving to git, I'm becoming more interested in how it works.
On a related topic, anyone using git in a way like how subversion does vendor branches? Currently I do a cvs export => svn with svn_load_dirs.pl, and I'd be really interested on any resources on how to best do this with core and contrib code.
Well I'm pretty much ignorant in SVN terminology but in Git, a branch is just a pointer to a given commit. So you can branch as much as you want.
git checkout -b my_new_branch [old_branch]
Now you're on my_new_branch that was created from old_branch. Work on it. The old_branch default is HEAD.
git checkout old_branch
You're back on old_branch. That's it.
Git always copies all files that change in a given commit. It doesn't keep deltas like others SCMs.
--- appa
On 30/04/10 03:12, Andrew Berry wrote:
On a related topic, anyone using git in a way like how subversion does vendor branches? Currently I do a cvs export => svn with svn_load_dirs.pl, and I'd be really interested on any resources on how to best do this with core and contrib code.
Where I can get a good git checkout [1] of the module I'm using submodules [2] for them all. This allows the superproject just to have info about where (what version) in the module it is. If I need to edit, patch, etc. the module for what ever reason I'm cloning it on a git repo I can write to and just moving the submodule to point there. Then creating actual branches (rather than a headless checkout - see [2] for explanations of the wierd terminology) that I can then commit to my repo for just that module. I'm actually even doing this for core, as a submodule of my superproject. It makes it easy to keep a single copy with patches (simpletest, the extra cron for drupal_queue etc.) and then switch them on the project. I'm guessing I could even add another tracking branch on pressflow - but I've not gone there yet. Cheers, ekes [1] I've stumbled for several modules as the tags don't seem to line up for CVS -> git conversions, so this isn't perfect till everything is moved to git http://github.com/sdboyer/drupal-git-scripts/issues/closed#issue/3 [2] http://book.git-scm.com/5_submodules.html
Hi, Most of them have given you the books, and other basic links. A couple of presentations that I found very useful. 1. A presentation by Linux Torvalds at google http://www.youtube.com/watch?v=4XpnKHJAok8 2. Another presentation at google by Randal Schwartz http://www.youtube.com/watch?v=8dhZ9BXQgc4 both interesting talks. Gordon. On 30/04/2010, at 7:34 AM, Domenic Santangelo wrote:
With d.o moving to git, I'm becoming more interested in how it works. Can anyone point me to a really solid primer? I've looked around at length and am having a tough time grokking how git works, especially in regards to multi-person development.
For example, I have one project that the previous dev set up to use git. For just me that's fine -- git add, git commit -a, git push, then reset to head on the dev server. But when more than one person is involved all hell breaks loose:
Say you and I edit the same .css file and for some reason there's a conflict (git seems very bad at merging .css compared to svn from my experience). In svn: svn ci, see you're out of date, svn up, resolve the conflict, svn resolved, svn ci, done. In git this is all confusing and you can even break MERGE_HEAD if you try to git pull after resolving a conflict and git will think you still have conflicts to resolve. It's all very troublesome.
From what I can tell, this is a common confusion coming from a "commit-update"-style system like svn; regardless, I still don't really get it. Any tips/articles/anything?
Thanks, -D
I usually like to keep all of my site specific changes in one place as well - makes it easy to figure out where I customized something. But recently I've come across a couple of other techniques that you might be interested in trying. Feature specific modules: these end up being modules that are customizing certain features - so if you have a blog feature for your site and you need to form alter it, or add a new view, or what ever, you create a site_blog.module and have all the various components there. Then you can simply svn up these particular changes in the particular modules. But most recently, I've gotten introduced the wide world of actual 'features', i.e the features module, which in a couple words is just a module wrapper which can hold configuration, upgrade paths, and makes the actual features generally easier to lump together when you have a particular feature that is implemented across multiple modules. The feature itself has a .module file as well so you can do your form alters, theme registry alters, or whatever customizations you need for that particular feature. So I guess in both instances it's separating your customizations out into whatever specific functionality that particular customization effects. This may mean multiple instances of hook_form_alter(), but it's a bit more reusable with the separation. On Wed, Apr 28, 2010 at 9:42 AM, nan wich <nan_wich@bellsouth.net> 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.
-- ~Jerad Bitner Lead Developer and Drupal Trainer at Lullabot http://lullabot.com
Use git-svn and then you have got branches (which areuch easier to merge than svn branches) and you also get git add interactive and hit stash as well. Sent from my iPhone. On Apr 28, 2010, at 7:42 AM, nan wich <nan_wich@bellsouth.net> 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.
participants (18)
-
Andrew Berry -
Antonio P. P. Almeida -
Brian Vuyk -
Dipen -
Domenic Santangelo -
ekes -
Gordon Heydon -
Jamie Holly -
Jerad Bitner -
Justin Ellison -
Khalid Baheyeldin -
Laura -
Lisa Sawin -
Matt Chapman -
Michael Prasuhn -
nan wich -
Nikola Kotur -
Victor Kane