[development] Git best practices for client codebases

[Marco Carbone]

"That keeps me on real releases, avoids unnecessary repository bloat, but
still gives me a full history of all work on that project specifically."

Well, svn or whatever VCS one is already using could be used this way as
well. And it doesn't really address the issue about managing patches, which
probably means that you either don't apply them (I doubt that), or you avoid
overwriting them by careful management (a patches directory or careful
monitoring of commit logs). But it's true that we aren't in the Wild West
days of Drupal 4.7/5 anymore where core patches were more common than not,
and so perhaps manual management is perfectly reasonable, and worth avoiding
the ball and chain of storing every Drupal commit ever.

-marco

On Tue, Mar 1, 2011 at 11:13 AM, larry at garfieldtech.com <
larry at garfieldtech.com> wrote:

> I think the question is more about non-custom dev history; there's little
> need for a client site to have the complete development history of Drupal
> 4.3 in its repo, for instance.
>
> Lately, what I've been doing/advocating is using Drush and real releases to
> download stuff from Drupal.org (core, contrib modules, etc.) and then
> checking the whole site into Git.  If I update a module, I use Drush for
> that and then update the code in my Git repo.  Then deploy to production
> using *my* git repo (which has my full dev history but not every commit in
> every one of my projects ever) and tags.
>
> That keeps me on real releases, avoids unnecessary repository bloat, but
> still gives me a full history of all work on that project specifically.
>
> --Larry Garfield
>
>
> On 3/1/11 1:56 AM, Sam Boyer wrote:
>
>> I tend to advocate full clone. You're talking about a task that version
>> control is designed for. Now that we've made the switch, IMO native
>> code:Git::bytecode:another VCS, or worse, patch stacks, etc. I don't
>> know what drush did before to "make this easy" - maybe pop off patch
>> stacks, update the module, then re-apply the patches? Fact is, though,
>> nothing Drush could have done under CVS can compare to patching with
>> native Git commits: your patches can speak the same language as upstream
>> changes, and you have all of Git's merge&  rebase behavior at your
>> fingertips to reconcile them.
>>
>> There are some occasional exceptions to this, but I really do think it's
>> a bit daft not to keep the full history. Keeping that history means
>> peace of mind that your patches (now commits) can be intelligently
>> merged with all changes ever made to that module for all time, across
>> new versions, across Drupal major versions...blah blah blah. Trading a
>> few hundred MB of disk space for that is MORE than worth it.
>>
>> cheers
>> s
>>
>> On 2/28/11 10:56 AM, Marco Carbone wrote:
>>
>>> Since a Git clone downloads the entire Drupal repository, the Drupal
>>> codebase is no longer so lightweight (~50MB) if you are using Git,
>>> especially as if you clone contrib module repositories as well.
>>>
>>> With CVS, our usual practice with clients was to checkout core and
>>> contrib using CVS, so that we can easily monitor any patches that have
>>> been applied, so that they wouldn't be lost when updating to newer
>>> releases.  (Drush makes this particularly easy.) This is doable with Git
>>> as well, but now there seems to be the added cost of having to download
>>> the full repository. This is great when doing core/contrib development,
>>> but not really necessary for client work. This is unavoidable as far as
>>> I can tell, but I don't think I'm satisfied with the "just use a tarball
>>> and don't hack core/contrib" solution, especially when patches come into
>>> play.
>>>
>>> Is there something I'm missing/not understanding here, or does one just
>>> have to accept the price of a bigger codebase when using Git to manage
>>> core/contrib code? Or is managing core/contrib code this way passe now
>>> that updates can be done through the UI?
>>>
>>> -marco////
>>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20110301/eb35b1b7/attachment.html