[Monetdb-developers] IMPORTANT: move of MonetDB repository imminent
On Monday, May 3, 2010, we are going to move the MonetDB repository over from the Sourceforge-hosted CVS repository to a Mercurial repository hosted on dev.monetdb.org. On March 18 I sent a pre announcement to the monetdb-developers list (IMPORTANT: changes are afoot). [1]
In particular, the following CVS modules will be converted and moved: MonetDB, MonetDB4, MonetDB5, buildtools, clients, geom, java, pathfinder, sql, template, testing. The other CVS modules that are hosted at Sourceforge (pf-haskell, pf-tools, xml) will remain there, at least for now.
This means that as of Monday, the affected modules in the CVS repository will be made read only (it will remain readable for a long time, just not writable). When the move is complete, the repository will open at the following location:
http://dev.monetdb.org/hg/MonetDB/
This URL can be used to browse the repository using a web browser, and it can be used as the URL to make a Mercurial clone (hg clone http://dev.monetdb.org/hg/MonetDB/). This will be a read-only version of the repository.
Core developers will get read-write access at the URL
ssh://hg@dev.monetdb.org/MonetDB/
I wrote a document to help with the conversion to Mercurial, both describing the way to use Mercurial, and how to convert your CVS working set to a Mercurial clone. For now (until we find a better place), this document can be accessed at:
http://homepages.cwi.nl/~sjoerd/downloads/monetdb/MonetDB-Mercurial.html http://homepages.cwi.nl/~sjoerd/downloads/monetdb/MonetDB-Mercurial.pdf
As part of the move, I will subscribe subscribers to the various monetdb checkin mailing lists to the new mailing list checkin-list@monetdb.org. If you are subscribed to one or more of monetdb-checkins@lists.sourceforge.net monetdb-sql-checkins@lists.sourceforge.net monetdb-pf-checkins@lists.sourcefoge.net I will subscribe you to the list checkin-list@monetdb.org. This I will do on Monday as well, so you should get a message to that effect on Monday.
[1] http://sourceforge.net/mailarchive/forum.php?thread_name=4BA239BF.4090307%40...
On 30-04-2010 22:27:24 +0200, Sjoerd Mullender wrote:
On Monday, May 3, 2010, we are going to move the MonetDB repository over from the Sourceforge-hosted CVS repository to a Mercurial repository hosted on dev.monetdb.org. On March 18 I sent a pre announcement to the monetdb-developers list (IMPORTANT: changes are afoot). [1]
Please be aware that also the SourceForge bugtracker will be migrated. Changes made to the bugtracker since 6:00am today will get lost. We will try to close the SourceForge bugtracker ASAP for this reason.
On 30-04-2010 22:27:24 +0200, Sjoerd Mullender wrote:
On Monday, May 3, 2010, we are going to move the MonetDB repository over from the Sourceforge-hosted CVS repository to a Mercurial repository hosted on dev.monetdb.org. On March 18 I sent a pre announcement to the monetdb-developers list (IMPORTANT: changes are afoot). [1]
Please be aware that also the SourceForge bugtracker will be migrated. Changes made to the bugtracker since 6:00am today will get lost. We will try to close the SourceForge bugtracker ASAP for this reason.
Where can I find the new bug tracker?
By slightly changing the test submitted with bug #2995671, I was able to trigger an unrelated bug (see the attached test file fallback-bid-collision.sql). In sql/src/storage/bat/bat_storage.mx, function delta_bind_bat, the conditional (temp || access == RD_INS || !bat->bid) leads to the iBAT being returned even if the main BAT is requested by sql.bind(...,0), when there is no main BAT in the sql_delta structure. As long as sql.bind(...,0) and sql.bind(...,1) are combined using algebra.kunion, this doesn't seem to create problems. But the mergetable optimizer's logic to optimize union computations based on overlapped MAT elements does not interact correctly with that behaviour, which leads to the data being inserted twice in the test file.
I have attached a patch (no-fallback-ibid.diff) which avoids this problem by disabling the iBAT fallback, creating an empty main BAT instead.
To improve the subset of possible interactions between components which is tested, have you considered a fuzz-testing-like approach?
Best regards,
Isidor
participants (3)
-
Fabian Groffen -
Isidor Zeuner -
Sjoerd Mullender