similar to: SVN migration

Xapian has turned 20! Strictly speaking it was 20 years ago last month but I managed to miss the true anniversary - the oldest commit in the Xapian repo is: commit 8ced76ea128c8fb2792477e09b41fa989f2e572f Author: Richard Boulton <richard at tartarus.org> Date: Fri Sep 10 09:50:40 1999 +0000 Martins initial code, which didn't work for him but did for me. Back then Richard,

I've been wondering if we should consider migrating from CVS to Subversion (aka SVN) for version control. There's a utility (cvs2svn) to convert a CVS repository while keeping full history. And SVN is supported by viewcvs (as used by http://cvs.xapian.org/) The main motivations are: * CVS doesn't really handle renaming files well. Either you "cvs rm" then "cvs

Olly and I have been discussing details of our policy for deprecating features, and we thought it would be useful to canvas users opinions on a particular aspect. From time to time, we remove features from the library (usually because we have a better replacement). To make life easier for users, we've been following a deprecation policy, so that users are given plenty of warning of

Does anyone know if xapian stemming support suffix -er? I tried -s and -ing both work, but not -er. _________________________________________________________________ ?????????????? MSN Messenger: http://messenger.msn.com/cn

On Feb 1, 2008 6:11 PM, Arnaud Quette <aquette at alioth.debian.org> wrote: > Author: aquette > Date: Fri Feb 1 23:11:33 2008 > New Revision: 1264 > > Log: > fix HAL support installation [Alioth Bug #304156] Arnaud, I tried to fix some of the errors that I was seeing in buildbot, but I still get the following error on "make distcheck", and I don't know how

This is an update on the current status of the relicensing, but also an opportunity to give feedback. Sorry it's rather long, but I think it's necessary to summarise the situation - there are probably list members who weren't even born at the start of the history of this! Xapian is currently licensed as GPLv2+, but isn't something we actually chose for Xapian, but rather due to a

(Forwarded off-list message) -------- Original Message -------- Subject: Re: [Xapian-discuss] what is the fastest way to fetch results which are sorted by timestamp ? Date: Thu, 11 Aug 2011 01:06:36 +0800 From: ??? <panjunyong at gmail.com> To: Tim Brody <tdb2 at ecs.soton.ac.uk> On Wed, Aug 10, 2011 at 6:39 PM, Tim Brody <tdb2 at ecs.soton.ac.uk> wrote: > Hi, > > In

With automake, we collectively need to check to see if 'make distcheck' still works after adding or removing files. Basically, nothing will make its way into the NUT distribution tarball unless it is somehow mentioned in one of the Makefile.am files. See the packaging/RedHat directory for an example. Niels, thank you for spotting the extra nut.spec file in SVN; however, it needs to be

Afternoon all. I was discussing the current licensing of Xapian and how it influences the way we work with someone at another OSS project recently, and although the upshot is likely to be that they'll amend their license (it's a corporate foundation, and GPL compatibility is something they desire for precisely this reason), it did prompt me to think about how we're tracking where we

I've now got working (but not necessarily policy compliant) debian packages for xapian-core, the xapian python bindings, and omega and omindex. I will be sorting out a public apt repository of these shortly. Is it appropriate to add the debian control files (ie, those files in the debian directories in CVS) to the distribution tarballs? I think yes - they don't take up much space,

Hi, I'm confused about my licensing obligation with respect to the Xapian SWIG bindings. I've got a python wrapper that sits above the standard Xapian Python/SWIG bindings, and I wasn't sure if the *intent* of the Xapian team is that my python wrapper - and any code that also uses my wrapper also falls under GPLv2. It seems unclear if the FSF's position on dynamic linking in

I'm starting to prepare the next release. Since 0.8.3 I've made a number of changes to get working builds working on HPUX and OSF, and made some of the Windows specific bits more robust. I'd like to check that these haven't broken CYGWIN or IRIX builds, but I don't have access to these platforms. If you are able to test, it'd be most appreciated if you could. Download a

On Wed, Mar 5, 2008 at 4:44 PM, Arjen de Korte <adkorte-guest at alioth.debian.org> wrote: > Author: adkorte-guest > Date: Wed Mar 5 21:44:41 2008 > New Revision: 1358 > > Log: > - fix HAL support [Alioth Bug #304156] (backport from r1294) > - only include target specific CFLAGS and LDFLAGS only if target is actually used (backport from r1296 and r1297) > - add

On Fri, 2011-12-09 at 03:46 +0000, Charles Lepple wrote: > Author: clepple-guest > Date: Fri Dec 9 03:46:11 2011 > New Revision: 3344 > URL: http://trac.networkupstools.org/projects/nut/changeset/3344 > > Log: > Force files to be overwritten (especially for libtool) > > Modified: > branches/nut-scanner_dlopen/autogen.sh > > Modified:

On Mar 20, 2004, at 1:07 PM, Ralph Giles wrote: > Ok, I'm starting the conversion. Please hold all commits until > further notice good luck! let me know how the cvs2svn script works out for you... I'm looking at doing the same soon with a ~800 file cvs repository I'm in charge of. /dale --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage:

One of the items on the ToDo list for version 1.0 at http://wiki.xapian.org/TodoFor1_2e0#preview is: "Rework Omega's indextext.cc as a xapian-core "TextSplitter" class." I've been wondering about this for a while now. Currently, we have the Query Parser in Xapian core, but no text processing. Clearly, it makes sense to have a "text splitter" class in

The xapian commits list seems to be broken at the moment: several commits I did over the weekend and yesterday haven't shown up in it: the last message I saw was on Friday 13th April at 17:41. I'm not an administrator for that list - Olly/James, can you investigate? -- Richard

There's a bit of an API glitch with Query objects at present. This code shows it off: Xapian::Database("/path/to/db"); Xapian::Enquire enquire(db); // make a simple query Xapian::Query myquery(Xapian::Query::OP_NEAR, phrase, phrase + 2); enquire.set_query(myquery); // Now change the query - this shouldn't affect the query enquire // will run, but it does.

bugzilla-daemon@ixion.tartarus.org wrote: > http://www.xapian.org/cgi-bin/bugzilla/show_bug.cgi?id=117 > > ------- Additional Comments From olly@survex.com 2007-04-05 13:52 ------- > I've actually already implemented a fix. If bugzilla stops sending me mail, I > might even manage to check it in soon! Sorry Olly - just about finished sorting things out now! For everyone

Hi Reid, > A deficiency in the cvs2svn script causes it to bloat the Subversion > repository (significantly, as in 10x) in the conversion of branches > and tags. It's probably a bit late in the day, but have you considered other CVS to SVN conversion tools, e.g. Tailor? http://www.darcs.net/DarcsWiki/Tailor http://darcs.arstecnica.it/tailor/ Cheers, Ralph.