There are a couple of ` s around the "last_revision" column in the install for mysql for the subversion repositories table.
I dont know what happens, but the net result seems to be that the column is missing:
(BTW, for now,
Within mysql, you can run this command to fix the problem:
alter table subversion_projects add last_revision int(4) NOT NULL default '0';
)
Cheers
Mark.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | subversion_mysql-0.1.patch | 7.07 KB | marquardt |
Comments
Comment #1
marquardt commentedI've attached a patch for the current 5.x-2.x-dev release which fixes the .install script for MySQL. The patched version works fine for me for a *fresh* install of the module.
Christian.
Comment #2
halkeye commentedI'll have to double check and find any code updates I did.
I did stop working on this for a while when I though that the summer of code project was going to replace it, but I know i fixed this before hand, and there's a reason there is no longer a last_revision on project.. I think...
Comment #3
markfoodyburton commentedJust to let you know, I'm putting some work into this project because I need it to work...
I have it now running, though I'm not convinced I have many of the bug's out of it yet...
I have added some extra functionality, but this _SHOULD_ be in a different module - so I need to factor it out before I submit patches....
The extra functionality is kind of cute - it adds a "mirror" mechanism, such that you can set up one repository to automatically add svn:external (s) to a different (mirror) repository.
Seems a little silly, but the real world situation is that I run an open source project, but sometimes we work on things that are not "public"... but none the less "fit in" with the public stuff. So, ideally people seeing these "private" things want access to a repository that shows everything, while everybody else only wants to see the public stuff.... I suspect this is probably the case for many businesses who may have overlapping repositories. The way I've implemented is, the admin sets this us, so that when new projects are set up and choose their repository, the right thing happens. Of course, I'm going to have to be careful which projects get to choose their repository, but that functionality is already there :-)
Anyway - I have fixed some things that seemed to be broken (for instance, if you put a local file for a repository, then it will update the passwd/auth files on that repro without cron jobs etc (which I find to be a little ugly if the repro is on the same machine as the drupal web server), so if you would like, I could submit what I have, as a "patch not to be included, but..."
Cheers
Mark.
Comment #4
halkeye commentedI've put up a fix
Comment #5
(not verified) commented