Actually, 

1. David stripped out the customised version we used to run from our git repo, so we should be the same as some upstream version. Note: adodb used to be inconsistent with their line feeds, so I wouldn't be surprised if you've just got whitespace diff's

2. There is not a public svn/cvs of adodb that i'm aware of - I'm not even sure that the author has one internally given some of the releases i've seen pushed out before.

3. Whilst it makes sense to **bugfix** the current release - our focus should be on features in the next release. I'm not sure whether to class the fact that our oracle support is broken [and always has been] as a "bug", or a new feature for the next release :)

Paul


On Wed, Oct 26, 2011 at 10:32 AM, Damien Regad <damien.regad@merckgroup.com> wrote:
On 26/10/11 08:45, David Hicks wrote:
> I wouldn't expect a new release of ADOdb any time soon. It's legacy
> software and doesn't get used as much as it used to.

I think that horse is not dead yet...

According to the sourceforge download page [1] a new version 5.14 was
released on Sept 8th, and that's the 4th release since the version we
have bundled with Mantis (5.10, dated Nov 2009)


 > The problem arises with distro packaging of MantisBT where bundled
 > libraries such as ADOdb, PHPMailer, etc are removed from the MantisBT
 > package and replaced with separate system-wide packages. This is the
 > correct thing to do and it should be our aim to assist distros by
 > continually trying to remove bundled libraries.
[...]
 > trying to avoid branching our bundled libraries from upstream
 > because it makes it very difficult to know which patches need reapplying
 > when it comes time to updating the bundled libraries to match new
 > upstream releases. At one point I think I was also committing the
 > patches as well, just to make the update process easier.

I don't think we comply with this today. According to
./library/adodb/readme_mantis.txt, there have already been some changes
made to the library. This is confirmed by comparing downloaded 5.10
library from sourceforge with 1.2.x HEAD:

$ diff -qrwB adodb5.10 ~/dev/mantisbt/library/adodb |grep -v ^Only
Files adodb5.10/adodb-datadict.inc.php and
../dev/mantisbt/library/adodb/adodb-datadict.inc.php differ
Files adodb5.10/adodb.inc.php and
../dev/mantisbt/library/adodb/adodb.inc.php differ
Files adodb5.10/datadict/datadict-mssql.inc.php and
../dev/mantisbt/library/adodb/datadict/datadict-mssql.inc.php differ
Files adodb5.10/datadict/datadict-mssqlnative.inc.php and
../dev/mantisbt/library/adodb/datadict/datadict-mssqlnative.inc.php differ
Files adodb5.10/datadict/datadict-postgres.inc.php and
../dev/mantisbt/library/adodb/datadict/datadict-postgres.inc.php differ
Files adodb5.10/drivers/adodb-db2.inc.php and
../dev/mantisbt/library/adodb/drivers/adodb-db2.inc.php differ
Files adodb5.10/drivers/adodb-mysqli.inc.php and
../dev/mantisbt/library/adodb/drivers/adodb-mysqli.inc.php differ
Files adodb5.10/drivers/adodb-odbc.inc.php and
../dev/mantisbt/library/adodb/drivers/adodb-odbc.inc.php differ
Files adodb5.10/drivers/adodb-odbc_mssql.inc.php and
../dev/mantisbt/library/adodb/drivers/adodb-odbc_mssql.inc.php differ
Files adodb5.10/drivers/adodb-pdo.inc.php and
../dev/mantisbt/library/adodb/drivers/adodb-pdo.inc.php differ
Files adodb5.10/drivers/adodb-postgres64.inc.php and
../dev/mantisbt/library/adodb/drivers/adodb-postgres64.inc.php differ
Files adodb5.10/drivers/adodb-sapdb.inc.php and
../dev/mantisbt/library/adodb/drivers/adodb-sapdb.inc.php differ

I haven't looked into full detail for all these differences, but I'm
quite sure that if distros use a "vanilla" version of ADOdb Mantis will
break considering the amount of changes made (added function params,
lots of added code for DB-specific drivers...)

So if patching a bundled lib is not possible, is there anything else
other than reporting upstream (which is already done), that I can do to
resolve the issue ?

Victor's idea of using git submodules for traceability sounds good as it
would offer traceability, but

 - I did not find an "official" source repository of ADOdb (the CVS on
sourceforge is completely out-of-date), there is a slightly outdated one
on github [2] but it seems specific to the owner's project
 - Is it worth the effort of building this, considering the intent of
moving away from ADOdb, as mentioned by David ? If we are not likely to
upgrade to a later version of ADOdb, then I would say no.


Bottomline is, based on the fact that ADOdb library is already
customized, I am not sure one more change would be a huge issue, keeping
in mind that without this fix, it will not be possible to implement
support for oracle as the generation of schema upgrade SQL script fails.

Let me know your thoughts.

Damien


[1] http://sourceforge.net/projects/adodb/files/adodb-php5-only/
[2] https://github.com/bitweaver/adodb


------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
mantisbt-dev mailing list
mantisbt-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev