I've been committing modules to Drupal CVS for years now, always using TortoiseCVS (if that matters), but since some time there's an issue I cannot solve and need your assistance.
Basically, the dev version of my module does NOT contain 2 files, namely
functions.inc
picasa.inc
See http://ftp.drupal.org/files/projects/brilliant_gallery-6.x-3.x-dev.tar.gz
If you look at http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/brilliant_g... ... there are 6 files.
bgchecklist.js
brilliant_gallery.css
brilliant_gallery.info
brilliant_gallery.install
brilliant_gallery.module
image.php
README.txt
views.inc
The first problem that there are 'dead' files, which I am not sure what it means. There are 6 of them. The missing files are among them, but there are also other 'dead' files like bgchecklist.js which however are in the dev package. So whatever 'dead' means it is probably not causing this problem.
Yesterday I used TortoiseCVS to remove the two files from CVS, then added them fresh, and committed. Today, after packaging, they are still not there.
Please advise. Thanks.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | Voila_Capture_17.png | 100.28 KB | avpaderno |
| #3 | Screenshot-brilliant_gallery-6.x-3.x-dev.tar-2 [read only].png | 81.54 KB | dave reid |
Comments
Comment #1
dave reidIt looks liek the files are in your DRUPAL-6--3 CVS branch just fine: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/brilliant_g.... The WebCVS link you posted is for the module's HEAD branch. Those files are considered 'dead' in the HEAD branch since they were either removed from HEAD or added on a different branch and not on HEAD (the latter is likely your case).
They're also in the development package as well. Keep in mind the development builds are only re-packaged every 12 hours, so changes are not immediate.
Comment #2
vacilando commentedThanks for the quick reaction, Dave.
Sorry for posting the head CVS link rather than the concerned one(for 6.3).
However, while http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/brilliant_g... indeed has the two missing files
functions.inc
picasa.inc
if you look at 6.x-3.x-dev they are not there. Yes, I did wait long enough for the packaging - you can see the two files were (re-added) 25 hours ago now.
Comment #3
dave reidThey're in the development build. Maybe it's not downloading it correctly? This is a screenshot of the download's contents on my computer.
Comment #4
avpadernoI downloaded the tarball archive, and I see the two files as well (see the attachment for a screenshot of the application I use for archives).
Bear in mind that the development snapshot archives are created just twice per day, differently from the official release archives.
Comment #5
vacilando commentedFolks, thanks for helping in this. It was a ... browser cache problem!
For days, Firefox 3.0.12 (on Vista 64b) kept giving me the same dev file. Even now, minutes ago, when I downloaded the dev package, it missed the two files. Seeing your screenshots I finally got the idea to try it on IE, and there it got me a newever version. Then I cleared the FFox cache and got the new file there as well.
Now, obviously I keep clearing the browser cache while developing and whenever I suspect a stale page, etc., but I'd have never expected that a .tar.gz file could be cached DESPITE the fact that the original had changed on the server.
I realize that any module I've downloaded (recently) several times in hope of getting the latest version might also have been stale.
Is there a way to have browser(s) recognize that the dev file (size and date) changed? (Normally I would think of adjusting generated headers, but these files seem to come from an FTP server directly, not through a PHP script.)
Comment #6
avpadernoI noticed I had the same problem with Firefox, on Windows. It was not exactly the same problem as your, but Firefox kept to show me a page from the cache, and I was not able to check if a module I was developing was working.
I didn't resolve the problem, and now I am using Mac most of the time.
Comment #7
dave reidI haven't ever had a problem with Firefox showing old downloads when re-downloading. Oh well. Since we've figured this out, marking as fixed.