Apps Icon displays folders in filer window.

Sounds like the mentality of the software authors responsible for a database used by one of the specialities. Works fine when dealing with a small/moderate number of records. Then they added the MPI1 feed that was part of the contracted setup.

A dedicated database is a different proposition than a filesystem.

If you use a content search tool, why bother naming your files? I understand searching the content of a database, though that is done by the database software not the file search facilities.

@Paolo. There is no need to apologise and I meant no offence.‘Dare say’ was meant as Rick said ’Paolo’s OS’ was to differentiate between variations e.g:- ROD, RComp, ROOL and so on. And as for ‘Invite only’ By that I meant the mailing list to be for people testing and evaluating your stuff. Not for the OS religious zealots wishing to push their points of view.

Regards.

Thx Ron :)

@ Chris Mahoney

Did I? I said RISC OS isn’t full of them (thinking of the type that drag down the system with ‘unnecessary’ processing, although I admit that this can sometimes be a fine line), but I don’t believe that I said I don’t like them. Indeed I’ve written my own!

Sorry, I must have misunderstood you then. In the mist of all the objections received, it sounded like also background processing was not desired.

bq. Hiding these files in the filer would make development directories tidier, and also help prevent content searches including the .git directory which will generate lots of unwanted hits from the object files.

I would be happy to update !Find (i.e. the underlying tool) to optionally skip such RCS dirs. It would improve my life somewhat, especially as our current out-of-date svn port pollutes every subdir with /svn.

Well that was easy! I have builds of the current DDE’s diff and find that skip /svn and /git directories – diff-nrcs and find-nrcs (-nrcs suffix = no RCS files) – which is my particular desire.

If a new command switch could be agreed upon, e.g. --exclude-vcs (as per gnu tar), that could be implemented for both the backend and frontend tools (tick option in Options menu I think). Easy enough to extend to ignore ‘hidden’ files (and dirs) if we agree on using the / prefix for them, e.g. --exclude-hidden-files.

if we agree on using the / prefix for them

Works for me, I’ll make sure to use /DirCfg and /DirIdx for my filer. I don’t think I am using hidden files for anything else right now.

OK, suitable options added to diff and find and frontend updates done too.

Interested parties can take a keek at: https://croftnuisk.co.uk/coltsoft-downloads/other/upd_df_xhv.zip

That contains diff-xhv and find-xhv that can be used in place of the ones supplied in the DDE. If you use the !Diff and !Find frontend tools, there are updated Desc files to support the two new options:

Exclude hidden (-xh on command line) = any dirs or files starting with /

Exclude VCS (-xv on command line)= version control system dirs and files (currently just /svn and /git, but I can take the full list from the gnu tar reference)

If neither option is supplied, the tools behave just as before. If you don’t update the frontend tools, you can supply -xh and/or -xv from the command line.

Very small change set – if people think it sensible, I’ll submit a pull request for them.

Still more off topic, I am minded to add -xa to exclude descending into archives / image files.

I would be happy to update !Find (i.e. the underlying tool) to optionally skip such RCS dirs. It would improve my life somewhat, especially as our current out-of-date svn port pollutes every subdir with /svn.

Not to drag this further off topic, but does anyone know where the source for the current SVN port is? I still use SVN, and I might need something to tackle once I’ve finished with SQLite :)

does anyone know where the source for the current SVN port is?

Is this the current version? If so, the source is here: https://github.com/ajw498/subversion

Nope. I have 1.6.12 (8-Mar-11), although I have no idea where it came from. If I recall correctly, there is/was another one in PackMan but it wouldn’t connect to VisualSVN Server.

If I recall correctly, there is/was another one in PackMan

There’s an entry in the autobuilder, under develop/subversion – I don’t know if that’s it?

I’m using the 1.6.17 svn client from PackMan (datestamp 2017; doc claims to be maintained by the GCCSDK team, and not Alex Waugh!) but being ancient it litters /svn everywhere.

I hate when updated servers won’t accept connections from old clients!

I’m using the 1.6.17 svn client from PackMan (datestamp 2017; doc claims to be maintained by the GCCSDK team, and not Alex Waugh!) but being ancient it litters /svn everywhere.

subversion is on the gccsdk autobuilder but no longer builds. It fails on not finding a dependency, db4.7.

In the real world svn is at 1.14.

I confess to having had limited success with the gccsdk autobuilder. Some things build fine, but others – well. I have never managed to get even sed built (must try harder), never mind subversion. Perhaps we don’t have to go too far back in Ubuntu time to find a revision where its idea of current source will allow 1.6.x subversion to build. I think having everything in /svn in the root dir came quite soon after (a svn 1.8 on linux I have does that [Edit: 1.7 seems to be where this was introduced]), so might be a feasible step from the 1.6.x patchset than racing ahead to 1.14.

I confess to having had limited success with the gccsdk autobuilder.

I know that feeling. The sources develop, the patches then don’t. Debian changes stuff. etc. etc.

OTOH sed builds here. An update was committed in Jan 21.

A new topic may be in order.

OTOH sed builds here. An update was committed in Jan 21.

Which Debian is that building on? I am inspired to give it another shot, as currently I can’t use the sed from PackMan to build Fireworkz and have to use a homebrew (truly archaic) one to get round the new one hanging. I’d like to solve that.

A new topic may be in order.

If only we could migrate posts…

Which Debian is that building on?

I am building on Ubuntu 20.04. The autobuilder searches Debian sources.

The sed just built is 4/7-1 which is the version on PackMan.