> Also, we run into the odd issue where files uploaded by developers on
thier local copies conflict with files uploaded on the staging server
(test.txt, anyone?).
To clarify on the above - developers don't add files to git on their
local copies, but a test file will sit in the developer's files
directory until manually deleted. If a file with the same name is
uploaded to the canonical server, and then pushed to git, the developer
will need to resolve the conflict before he can merge the latest updates
with his local site.
On 11-02-18 11:41 AM, Brian Vuyk wrote:
Ah, I misunderstood.
We take it on a case-by-case basis.
1. The imagecache directory is always excluded, as those are
automagically regenerated anyways if they don't exist. We also exclude
the 'js' and 'css' folders, as putting the aggregated js and css files
in git is pointless.
2. We generally exclude the files directory altogether, and just put
up with broken images on our local dev environments.
3. If absolutely necessary, we may rsync the files directory down to a
dev environment periodically.
We have on occasion tried to keep small copies of the files directory
in git, but we run into problems where nodes are deleted on the site,
and Drupal deletes the corresponding file from the filesystem.
However, having not been removed from git with 'git rm <filename>',
someone has to push the filesystem changes with 'git add -u' to make
the files directory sync properly. Also, we run into the odd issue
where files uploaded by developers on thier local copies conflict with
files uploaded on the staging server (test.txt, anyone?). This often
needs sorting out...
All-in-all, it's extra work with little extra gain, other than prevent
some broken images or file links on the non-canonical copies of the
site, which can be fixed as needed by rsyncing the files directory
down to the non-canonical development copies.
In short, I keep all the site code in git. For anything that's not
code (or part of a code package, such as theme or module images), I
try to leave out unless there is a good reason for inclusion.
Brian
On 11-02-18 11:18 AM, Andy Fowlston wrote:
Brian wrote:
From a db point of view this sounds very similar to what we do.
Could you elaborate on how you keep the files in sync?
Keep which files? The database exports?
Sorry, no not the database at all: I'm wondering about any content
related files in the files directory (I presume you use source
control for everything outside the files directory?).
We look at it this way - staging is the canonical database. All config
is done on staging, never in the developer-specific local environments.
Yeah, that's how we're doing things at the mo. I'd like to move more
(ideally all) of the config to source files, but we're not there yet.
Thanks,
Andy
. . . . . . .
Andy Fowlston
+44 (0)20 8747 5068
[email protected]
Skype: andy.pedalo
www.pedalo.co.uk
This email is intended only for the above named addressee/s. This
email may be confidential or legally privileged. If you have received
this email and you are not a named addressee, you must not use, copy,
distribute or disclose the email or any part of its contents or take
any action in reliance on it. If you have received this email in
error, please email the sender by replying to this message and delete
it from your system. All reasonable precautions have been taken to
ensure no viruses are present in this email.
pedalo limited cannot accept responsibility for loss or damage
arising from the use of this email or attachments and recommends that
you subject these to your virus checking procedures prior to use. Any
views or opinions presented are solely those of the author and not
necessarily those of Pedalo Limited
Please consider the environment before printing this email
