Yeah, I don't patch core often enough to need an elaborate patch
management system. :-) Just checking patch files that are clearly named
into the repo is usually fine.
--Larry Garfield
On 3/1/11 10:30 AM, Marco Carbone wrote:
"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, [email protected]
<mailto:[email protected]> <[email protected]
<mailto:[email protected]>> 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////
