Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
An attempt to commit the new ADOdb 5.11 library to XRMS's CVS yesterday ended up somehow corrupting the directory structure of the /include/adodb folder. It now contains several subdirectories with the same names as the PHP and XML files which are supposed to be there, e.g. instead of the file:
there is a subdirectory in /include/adodb/drivers named adodb-pdo_oci.inc.php (/include/adodb/drivers/adodb-pdo_oci.inc.php/).
This has made it impossible to commit these particular PHP and XML files since CVS does not allow a file and a directory with the same name in the same location. For those of you who have experience with CVS, you would know that there is no way to actually remove a directory from the repository without modifying the repository manually (not a particularly good idea). To top it all off, the tool SourceForge provides to make such a modification (repoadmin) is currently disabled, possibly because of the recent attack on the site.
As a result, checking out XRMS from CVS presently will not yield the desired results and I would advise against doing that until the issue is resolved unless you are comfortable manipulating your local copy.
If you have checked out XRMS since yesterday (Feb 14, 2011) and have issues with ADOdb errors, you can get your local copy working by deleting the /include/adodb folder locally and renaming the new /include/adodb4.68 folder which was committed yesterday to /include/adodb to get the system working with the old ADOdb. Alternatively, you can delete the /include/adodb directory (again locally) and place a freshly downloaded copy of the ADOdb 5.11 library in its place (make sure to rename the /adodb5 folder the library comes packaged in to /adodb). I have had XRMS running on PHP 5.3 with the ADOdb 5.11 library on my development box for a couple of weeks now without any issues. However, either of these approaches are temporary solutions only and you will need to revert those changes and re-check-out the /include/adodb folder once the repository is back to normal. If you are not having any problems at the moment, I would advise to simply wait it out and not make any CVS updates until the issue is resolved.
I have raised a support ticked with SourceForge to help me prune the rogue directories but, in the meantime, I am becoming more and more tempted to simply migrate XRMS from CVS to Subversion. CVS does a good enough job for routine single-file commits, however, bigger commits are always a challenge. This is not the first time I have had issues with it, including one time when I had to manually force-commit about 300 files, one at a time, in a library upgrade and there are at least two other empty directory trees that I am aware of within the XRMS directory structure which may have been the result of similar library upgrades done by other XRMS developers in the past. CVS will eventually be phased out by SourceForge and making the move now should help to resolve the current problem as well as use a system that is more up-to-date and flexible. Migrating to Subversion is pretty easy on the user end as well.
Sorry for any inconvenience all of this may have caused! I will post any new updates to this issue in this thread and will hope to have it resolved one way or another within the next few days.
Thank you for your patience!
Stefan Pampel / polyformal
If you consider to start a change of the Version Control System, I recommend the use of a distributed VCS like mercurial or git.
Just my 2 Cents
Unfortunately, no change on the fix of the corrupted directories. I still cannot commit ADOdb 5.11 to the repository but, as long as this is the only issue, we can manage around it. The ticked I raised with SourceForge has been assigned but there has been no other movement on it. For reference sake, the errant directories that have messed up the ADOdb upgrade are:
You can see those if you browse the CVS repository here or if you check out CVS on a Linux machine. You will not see the errant "directory-instead-of-file.php" directories on Windows even if CVS reports your check out is up-to-date!
I also wanted to point out that you can pick up recent CVS commits after the corruption and update your local codebase as long as you do not update the /include/adodb directory - this is the only corrupted directory; everything else works fine.
As far as switching VCS, I am certain I will do it - CVS has been causing problems for me in the past even though, before this recent corruption they were relatively minor. This last one was just the last drop.
As for mercurial or git, I am concerned that the complexities they bring may outweigh the benefits of them being distributed especially in the current state of the XRMS project where there is really only one developer committing code. Subversion seems to offer the advantages I need right now without the complexity or learning curve obstacles. Would you care to comment on any particular advantage they may offer that would still make them a better choice?
Thanks for the input and have a great weekend!
I am happy to announce that, after I found out that adminrepo and rsync are back online, today I finally tackled the corruption of the /include/adodb folder in CVS. I have committed the ADOdb 5.11 library and the entire codebase stored in CVS should be back to normal now.
Thank you all for your patience. We are finally back on track :)