jd3 port to QM
Cedric
So I've just released a very very simple port of jd3 to QM. It works
great with the pool management part and I'm able to call subroutines.
I didn't test further cause I only need the soubroutines part.
Jd3 is a old socket/pool server running on D3. I've been using it
since years.
Please feel free to test it or even to port it more on QM !
https://sourceforge.net/projects/jd3/
Diccon
(Still have to put up Eungene's FILE.STAT :P )
You didn't need to setup a sourceforge, we would have happily given
you a spot on the SVN repo for GPL-QM.
Still source forge are good, and you have an assurance your in full
control.
I will try and test around the API for you, let you know how it all
works.
-Diccon
Steve Bush
close to an implementation of qmclient but written in Basic and with
pooling.
Pros: Easier to do customised security and logging etc program since it's
basic. Pooling. Logging of requests.
Cons: Slower in Basic? Missing qmclient style security (do anything/only
calls/only call special subs) although mitigated by ability to customise the
server side with your own security checks.
It consists of a main program "server" that accepts initial connections and
starts up processes of the (perhaps confusingly?) "client" program which
takes over and handles further requests.
equ CP.SHUTDOWN.AMC to 0
equ CP.LOGON.AMC to 1
equ CP.LOGOFF.AMC to 2
equ CP.EXECUTE.AMC to 3
equ CP.CALL.AMC to 4
equ CP.SELECT.AMC to 5
equ CP.OPEN.AMC to 6
equ CP.READNEXT.AMC to 7
equ CP.READ.AMC to 8
equ CP.READU.AMC to 9
equ CP.WRITE.AMC to 10
equ CP.RELEASE.AMC to 11
equ CP.DELETE.ITEM.AMC to 12
equ CP.CLOSE.AMC to 13
equ CP.TEST.EXIST.AMC to 14
equ CP.LOCK.AMC to 15
equ CP.READV.AMC to 16
equ CP.SELECT.TCL.AMC to 17
equ CP.NOOP.AMC to 18
equ CP.STATUS to 19
equ CP.MNGMNT.AMC to 20
2. There are a few utilities to aid in configuration and server management.
3. I couldn't immediately find examples of precisely how to call it. From
basic? From anything php? Anything making qm more accessible to other
environments interests me.
Steve
Diccon
moment really lol. (I also withdraw my previous irrelevant comments
about the SVN lol)
I hadn't realised it was a drop in replacement for QMClient.
Cedric, can you supplement both of our cursory glances with a quick
"Whats great about JD3" kinda blurb.
I want to know if we shouldn't be moving in that direction instead.
Is the JD3 project very active? Joint ventures may be better than just
us.
I think Steve's initial assessment matches my own, and is a bit more
in depth. (I've been looking at it for 10 minutes and downloaded the
server app). So there are a couple of things QMCLient has that JD3
doesn't. But making those in JD3 may be easier than the reverse.
Diccon
GPL.BP directory in QMSYS.
-Diccon
Steve Bush
Cedric
On Mar 13, 1:18 pm, Diccon <diccon.tes...@gmail.com> wrote:
> Fantastic. I will try it out asap.
> (Still have to put up Eungene's FILE.STAT :P )
>
> You didn't need to setup a sourceforge, we would have happily given
> you a spot on the SVN repo for GPL-QM.
> Still source forge are good, and you have an assurance your in full
> control.
current jd3 project.
Thanks,
Cedric
Cedric
> starts up processes of the (perhaps confusingly?) "client" program which
> takes over and handles further requests.
> 3. I couldn't immediately find examples of precisely how to call it. From
> basic? From anything php? Anything making qm more accessible to other
> environments interests me.
* Put all the jd3-qm server in QM in a jd3 file. Compile and catalog.
* j-config could create all the configuration config. Some of the
options like pool management does not really work well, need more work
even on d3.
* j-startup will start for you one d3server and some d3client phantom
processes.
From there, you have the server part running. You can use the client
side program in php for example.
Your php program will connect to the server requesting for a process
to do some jobs. d3server will send you a socket port number
(d3client). Your php program will then connect to this d3client and
request for example for a call and will send you back the result. Here
we are !
We've been using jd3 since years and some of them are serving more
than 200 000 pages per month with just 4 d3client.
It's really a good product !
Cedric
Cedric
> Is the JD3 project very active? Joint ventures may be better than just
> us.
supporting it and using it in real world application. It's really a
great piece of software. We don intend to migrate some of our web apps
from D3 to QM with jd3.
Cedric
Steve Bush
stimulating rivalry and perspective (+) while at the same time dissipating
resources (-).
Pooling is good but moving away from QM's built-in somewhat definitive
protocol could be a loss. A hard call.
> -----Original Message-----
> From: openqm-o...@googlegroups.com
> [mailto:openqm-o...@googlegroups.com] On Behalf Of Cedric
> To: OpenQM-OpenSource
> Subject: [OSS] Re: jd3 port to QM
>
>
>
ash.c...@gmail.com
> Sounds like KDE versus Gnome :) i.e. a double edged sword providing
> stimulating rivalry and perspective (+) while at the same time dissipating
> resources (-).
>
> Pooling is good but moving away from QM's built-in somewhat definitive
> protocol could be a loss. A hard call.
could be swapped over easily? Hope this is not a dumb question, as
I've not looked at JD3 at all. I'm hoping to grab some time over the
weekend to do it - along with writing an internal webserver for QM !
>
>> -----Original Message-----
>> From: openqm-o...@googlegroups.com
>> [mailto:openqm-o...@googlegroups.com] On Behalf Of Cedric
>> Sent: 13 March 2009 22:18
>> To: OpenQM-OpenSource
>> Subject: [OSS] Re: jd3 port to QM
>>
>>
>>
>> > Is the JD3 project very active? Joint ventures may be
>> better than just
>> > us.
>>
>> Nop. I know that some are using it but mainly I'm the only
>> one supporting it and using it in real world application.
>> It's really a great piece of software. We don intend to
>> migrate some of our web apps from D3 to QM with jd3.
>>
>> Cedric
>> >
>
>
> >
>
Ashley Chapman
Steve Bush
Although having said that, probably for the vast majority of sites, pooling
is probably more associated with playing commercial "per user" style
licensing rules as it is with performance issues - and that just isn't an
issue here as has been stated already.
geneb
C# against a D3/Linux machine and it worked out very well. I'm very
encouraged to see this set up! I'm going to have to play around with
it when I get a chance.
I should also mention that the jd3 library has great "native" mv data
handling that works very well.
g.
Steve Bush
> 3. I couldn't immediately find examples of precisely how to
> call it. From basic? From anything php?
Found the client side libs for com, c#, java, php and python clients with
various dates from 2001 to 2008. That either indicates they work so well
that they don't need updating or they are defunct. No doubt we will find out
in time. The wire protocol looks very easy.
Cedric Fontaine
> Sounds like KDE versus Gnome :) i.e. a double edged sword providing
> stimulating rivalry and perspective (+) while at the same time dissipating
> resources (-).
>
> Pooling is good but moving away from QM's built-in somewhat definitive
> protocol could be a loss. A hard call.
>
I understand that, as I have worked on several opensource project. But
as we have many websites using jd3, it s probably easier for us to port
jd3 to QM. No that principles are here, any help is welcome.
Cedric Fontaine
Diccon
If the JD3 project has more coders available, better features or is
just written better I'll drop my work on QMClient. Unlike some of my
work colleagues I see no loss in doing something like that. Its all
experience.
If I'm honest the weight of being the only developer for QMClient was
getting a bit much, for server and all libs :P And combining effort
would be great.
Martin has already told me that he has a couple of plans for QMClient,
one secret, the other is encryption. Neither of which he will be
releasing to GPL-QM. Wasn't even particularly responsive to keeping
each other informed so we could remain cross compatible (IE his
commercial customers could use my libs/mods). Which amazes me, he'd
essentially be getting multi platform API library's for a tiny bit of
co-operation, but alas no. I have no qualms about developing SSL
encryption for QMClient, had planned it way before Martin mentioned it
to me (from day 1 of my involvement in fact).
So I have to emphasize we will be getting nothing from Ladybridge.
QMClient for GPL-QM will be ours only. As such moving to something
that potentially could draw in others from D3 as a separate drop in
module for QM would be fantastic.
Potentially we can work to keep JD3 going for Commercial QM as well,
if people like Kevin will test it for us.
Gnome vs KDE gives diversity and competition, true. But as i see it
it's gonna be Cedric vs me with JD3 vs QMClient, and I'd rather work
together ;)
I'll bow to popular vote, but i'm leaning towards serious trial and
joint venture with JD3. Extensive testing would be needed before we
actually decide anything.
Everyone whos giving JD3 a go, keep at it. As much research/trial data
as possible pls1 :D (C#? we dont have that?! lol)
If we try it and it fails, I can just pick up with QMClient where I
left off. We only loose time.
Also, Ashley. Good point. Don't think any extra work is necessary to
make them work on the same system already. Providing they work on
different ports. JD3 is just a BASIC program that you compile and run
on QM. QMClient is a basic program compiled into QM and callable via a
switch at command line (Allowing xinitd to call it from command-line).
Steve, yeah pooling is partly a licence fandango, but as has been
pointed out to me, web developers also seem to really want it for
performance.
Steve Bush
regions of the earth and back next Friday. Cheers, Steve.
ash.c...@gmail.com
> If the JD3 project has more coders available, better features or is
> just written better I'll drop my work on QMClient. Unlike some of my
> work colleagues I see no loss in doing something like that. Its all
> experience.
Is that Dad or Sis ? ;-) - (Only kidding around)
> If I'm honest the weight of being the only developer for QMClient was
> getting a bit much, for server and all libs :P And combining effort
> would be great.
This JD3 project was completely unknown to me, but then I'm mainly
familiar with the Revelation family of MV products. It looks like a
nice little project that's been running for years, and it's time had
finally come. Good work Cedric in bring it to our attention, and
doing a QM port.
I wonder what other, similar projects are out there?
> Martin has already told me that he has a couple of plans for QMClient,
> one secret, the other is encryption. Neither of which he will be
> releasing to GPL-QM. Wasn't even particularly responsive to keeping
> each other informed so we could remain cross compatible (IE his
> commercial customers could use my libs/mods). Which amazes me, he'd
> essentially be getting multi platform API library's for a tiny bit of
> co-operation, but alas no. I have no qualms about developing SSL
> encryption for QMClient, had planned it way before Martin mentioned it
> to me (from day 1 of my involvement in fact).
> So I have to emphasize we will be getting nothing from Ladybridge.
Let's not prod that hornet nest...
> I'll bow to popular vote, but i'm leaning towards serious trial and
> joint venture with JD3. Extensive testing would be needed before we
> actually decide anything.
Lovely.
> Everyone whos giving JD3 a go, keep at it. As much research/trial data
> as possible pls1 :D (C#? we dont have that?! lol)
Actually, I've got a C# prospective project, that might come up. But
it's way over the horizon at the moment.
> Steve, yeah pooling is partly a licence fandango, but as has been
> pointed out to me, web developers also seem to really want it for
> performance.
I've seen a simple page that reported in the bottom line that it took
83 SQL queries to generate. With that sort of thing, the
startup/shutdown overhead would be very significant. I wonder if
that's the root problem? Much less of a problem with multivalue.
Just my theory. Shoot it down in flames if I'm talking rubbish.
Ashley Chapman
Diccon
On 14 Mar, 22:30, "ashley.chap...@billabong-services.co.uk"
> > I have no strong ties to the QM Client system.
> > If the JD3 project has more coders available, better features or is
> > just written better I'll drop my work on QMClient. Unlike some of my
> > work colleagues I see no loss in doing something like that. Its all
> > experience.
>
> Is that Dad or Sis ? ;-) - (Only kidding around)
>
due for a massive update at some point.
Oh and Dad ;)
Given all our contractors are on "leave" during the recession lol.
In answer to your theory, perhaps. SQL is a hideously vague language
in which you need to specify optimisation to avoid useless access.
(Oracle has "hints" you give it in the rem notes of a query, it may
choose to ignore :P ). With MV you generally do the collection/
manipulation yourself. Except for Access reports. Certain multi
layered data (normally normalised in an SQL DB) is in the same record
with MV, so less joining query's. The question of what kind of loop
you do to "join" tables becomes irrelevant. And if you do normalise
Pick into separate files you can choose to do an "inner join" outer
join or paint the walls blue with records, which you don't usually
have the option of with SQL :D
So good theory, would love to see some performance benchmarks with two
side by side systems :) Might run one some day.
I know Cache, running its native OO db underneath, or running these MV
compatibility layer runs DAM fast from lack of traditional constraints
of relational databases. Dan designed some cruel queries with hundreds
of millions of records of test data, fared well. So we have to try the
same for QM someday.
-Diccon
Gene Buckle
>
> I have no strong ties to the QM Client system.
> If the JD3 project has more coders available, better features or is
> just written better I'll drop my work on QMClient. Unlike some of my
> work colleagues I see no loss in doing something like that. Its all
> experience.
> If I'm honest the weight of being the only developer for QMClient was
> getting a bit much, for server and all libs :P And combining effort
> would be great.
>
jd3 "protocol" into OpenQM?
> Martin has already told me that he has a couple of plans for QMClient,
> one secret, the other is encryption. Neither of which he will be
Secret? Must be huffing the same paint the TigerLogic guys are. :)
He's apparently not beyond purposefully breaking communication layer
compatibility to make sure
he can still cast aspersions on the GPL version. "See! They can't
even talk to the Commercial version any more!"
*ahem*
> Potentially we can work to keep JD3 going for Commercial QM as well,
> if people like Kevin will test it for us.
>
If Kevin's not available, the single-user developer version would be
sufficient to do compatibility testing.
> Gnome vs KDE gives diversity and competition, true. But as i see it
> it's gonna be Cedric vs me with JD3 vs QMClient, and I'd rather work
> together ;)
>
> I'll bow to popular vote, but i'm leaning towards serious trial and
> joint venture with JD3. Extensive testing would be needed before we
> actually decide anything.
>
As an opposite to the question I asked above, would any benefit be
realized in making the jd3 client understand the QMClient protocol?
> Also, Ashley. Good point. Don't think any extra work is necessary to
> make them work on the same system already. Providing they work on
> different ports. JD3 is just a BASIC program that you compile and run
> on QM. QMClient is a basic program compiled into QM and callable via a
> switch at command line (Allowing xinitd to call it from command-line).
I'll be damned. Ya learn something new every day. :) Maybe add jd3
compatibility into the QMCLIENT subroutine then?
g.
ash.c...@gmail.com
That's not quite what I meant. I'll try to be clearer...
In order to build a page, a PHP application might have to use many
more SQL queres, than if it was a MV application. In the SQL
scenario, the database connection startup/shutdown overhead is a high
proportion of the whole page build time. This is perhaps why
connection pooling is seen as so important to the PHP developer, and
the connection limit/licence count further enhances the desire for a
this pooling mechanism.
What this does imply to me, is that the application is being
constructed as a simple client server application. Much of the
business logic being in the PHP layer, outside of the database
connection.
An alternative would be to have an intermediate layer, within the
database, providing the business logic. Then there really would be
much less need for this pooling mechanism.
This is what I've done on a few of my applications, and the result is
that only one database login/logout is performed per page. Thus the
overhead is reduced to a tiny percentage, and not worth fussing over.
It's not particularly clever, as MV has a nice simple language for
building this. Doing the same with a SQL database often requires a
third party add-on. Unless you're masochistic enough to try it in
PL/SQL!
This is one of the really powerful features of Multivalue, which is so
poorly communicated to outsiders.
Ashley Chapman
Diccon
> connection pooling is seen as so important to the PHP developer, and
> the connection limit/licence count further enhances the desire for a
> this pooling mechanism.
>
> What this does imply to me, is that the application is being
> constructed as a simple client server application. Much of the
> business logic being in the PHP layer, outside of the database
> connection.
>
> An alternative would be to have an intermediate layer, within the
> database, providing the business logic. Then there really would be
> much less need for this pooling mechanism.
>
> This is what I've done on a few of my applications, and the result is
> that only one database login/logout is performed per page. Thus the
> overhead is reduced to a tiny percentage, and not worth fussing over.
> It's not particularly clever, as MV has a nice simple language for
> building this. Doing the same with a SQL database often requires a
> third party add-on. Unless you're masochistic enough to try it in
> PL/SQL!
>
> This is one of the really powerful features of Multivalue, which is so
> poorly communicated to outsiders.
>
> Ashley Chapman
mentioned elsewhere, I try and get the server to process and refine
data as much as possible before interacting with the client. The
server then has a very much more application orientated goal rather
than a generic database role. Put simply half my application logic is
in Pick/BASIC on the server, half is in the client interface in Java,
or PHP (or whatever). This can lead to astonishing speed. As well as
tremendous combination of fast local validation and interaction, and
yet still allow central locking, notification and information flow
between users. Something which I've just not seen anywhere else in the
same fashion on such pitiful hardware (with the exception of Cache).
But its apparent speed, because the work is the same, but the
bandwidth is much more efficiently used and the workload is in fact
distributed over both server and client proportionally. It's not brute
force, its programming smart.
It sounds Ashley like you do the same. Although you might call your
Basic simple, as you said it's much more capable than SQL's server
side options. Oracle does have various scripting and functional calls,
putting aside performance pick is far far easier to develop in. Most
other DB's, like MySQL, don't have very capable way of handling data
server side. Not beyond the generic data collection and processing
sense. So your very simple basic routines are in fact a very clever
decision to put the work there instead of in the PHP, as well as the
reverse when appropriate. Complex checks, cross file, like if an
account is on hold, as well as if the customer is US or UK and have
any credit on their account. All done before the result is sent back
to the client. Some of our older applications have a series of very
complex statisticle and estimating routines that crunch as away on the
server regualry an just pop the results out to the client PC.
Such splitting of the application logic is very hard with modern
languages and environments, given the lack of options for server side
processing with DBs like MySQL. My experience in Pick actually lead me
down the path of looking at 100% server based systems (eg terminal
based), and heavy Client weighted half breeds like a Java or .Net
application with SQL backend, as two sides of a coin. It was the
subject of my final year dissertation, where I tried to create the
best of both. Trying to get modern languages to lend themselves back
to letting more application logic, perhaps even all of it, back onto
the server.
So very dear to my heart ;)
But I personally wonder if that's what QM can offer to the world. Not
necessarily just Multi value, which we try and sell to the common or
garden consumer, but a server centric application distribution.
Putting your program logic back on the big powerful black box again,
in layman's terms :) With buzzwords like Virtual machines and Cloud
Computing floating about, let alone web applications being in popular
demand, perhaps we can sell ourself into that market more. One we
already occupy, but just don't realise it's significance :) Server
heavy applications. Your work with Web apps is a step in exactly the
right direction. Taking QM where it will get noticed, and where it
should perform well.
Some of this might grate, I don't know. I'm a little rusty on
describing it all. Maybe your all ahead of me ;)
But I do know for anything to happen for QM, the interconnections with
other languages/systems need to be there. And they need to be good.
-Diccon
Diccon
-Diccon
On 15 Mar, 05:24, Gene Buckle <f15...@gmail.com> wrote:
MAV
Great work and great news for developing JD3 in QM platform because we
use it with PHP and D3Linux in some web apps (and JD3, C# with D3NT)
and we were thinking about translating JD3 to QM. Usually, we use only
"call" method and D3Item class but We think JD3 is a great piece of
software.
Marcos Alonso Vega
Diccon
*Burns his QMClient API Docs then realises he left his pin number
written in there*
Dang it!?
(I am joking, besides you'd need to figure out my card number :D )
Ruby + rails research today. On-Site work tomorrow. Will try and look
at JD3 properly friday.
-Diccon
Gene Buckle
We might want to rename that class to MVItem now that it's no longer
exclusively a D3 interface. :)
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
OpenQM - A Multi-Value database for the masses, not the classes.
http://gpl.openqm.com - Get it _today_!
Gene Buckle
>
> Nice.
> *Burns his QMClient API Docs then realises he left his pin number
> written in there*
> Dang it!?
> (I am joking, besides you'd need to figure out my card number :D )
>
> Ruby + rails research today. On-Site work tomorrow. Will try and look
> at JD3 properly friday.
Diccon, if you have any questions, drop into ##pick or #openqm.
Cedric Fontaine
Currently only call is supported... Feel free to test the d3item part.
Cedric
MAV
Thanks,
Marcos Alonso Vega
Diccon
I've downloaded it in two test systems now, but still not quite got to
running it up lol.
-Diccon
Diccon
I've created an account, thrown the contents of the zip into a
directory file and compiled everything. Ran J-Config, used all the
defaults.
If I run up J-STARTUP it just runs and then;
Phantom 45 : Abnormal termination.
I tried running debug mode, nothing different. So I rand D3server
directly;
D3SERVER
0000032A: Unassigned variable SOCK at line 176 of D3SERVER
I can't understand why its complaining about an Unassigned var there.
This line is where the CONNECT.SOCKET function assigns SOCK, so it
shouldnt/wouldnt be set. Tried setting it to "" as a fix, but it
throws a horrid Seg fault. I cant see anything wrong about it in or
around the code.
Anyone know what I'm doing wrong/missing?
-Diccon
Fedora 10
Run as user with full permissions on the account dir.
ash.c...@gmail.com
>
> Any one get trouble with JD3?
> I've created an account, thrown the contents of the zip into a
> directory file and compiled everything. Ran J-Config, used all the
> defaults.
>
> If I run up J-STARTUP it just runs and then;
> Phantom 45 : Abnormal termination.
>
> I tried running debug mode, nothing different. So I rand D3server
> directly;
>
> D3SERVER
> 0000032A: Unassigned variable SOCK at line 176 of D3SERVER
>
> I can't understand why its complaining about an Unassigned var there.
> This line is where the CONNECT.SOCKET function assigns SOCK, so it
> shouldnt/wouldnt be set. Tried setting it to "" as a fix, but it
> throws a horrid Seg fault. I cant see anything wrong about it in or
> around the code.
>
D3CLIENT compiles but with warnings that SKT$STREAM AND SKT$TCP are
not assigned.
These values should be defined in SYSCOM:KEYS.H, but are only present
in the commercial version. So it looks like new flags have been added
to the socket interface. These new values appear in KEYS.H:-
* Socket types:
$define SKT$STREAM 0x00000000
$define SKT$DGRM 0x00000100
* Protocols:
$define SKT$TCP 0x00000000
$define SKT$UDP 0x00010000
$define SKT$ICMP 0x00020000
It appears that commercial version, which Cedric has ported JD3
against, has been updated. Anybody know how to apply similar updates
to the GPL release?
Ashley Chapman
ash.c...@gmail.com
> It appears that commercial version, which Cedric has ported JD3
> against, has been updated. Anybody know how to apply similar updates
> to the GPL release?
Replying to my own post. :-)
The subversion repository has been updated to include these bits. I
should update my system first...
--
Ashley Chapman
Gene Buckle
> not assigned.
>
> These values should be defined in SYSCOM:KEYS.H, but are only present
> in the commercial version. So it looks like new flags have been added
> to the socket interface. These new values appear in KEYS.H:-
>
> * Socket types:
> $define SKT$STREAM 0x00000000
> $define SKT$DGRM 0x00000100
> * Protocols:
> $define SKT$TCP 0x00000000
> $define SKT$UDP 0x00010000
> $define SKT$ICMP 0x00020000
>
>
> It appears that commercial version, which Cedric has ported JD3
> against, has been updated. Anybody know how to apply similar updates
> to the GPL release?
>
Ashley, you're not using the "right" version. :) Those two options were
added when I re-wrote all the socket interface code. You need to update
your version to the workdev1 branch.
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://www.scarletdme.org - Get it _today_!
ash.c...@gmail.com
>> against, has been updated. Anybody know how to apply similar updates
>> to the GPL release?
>>
>
> Ashley, you're not using the "right" version. :) Those two options were
> added when I re-wrote all the socket interface code. You need to update
> your version to the workdev1 branch.
>
Okay, I've tried to update, using tortoise. I get this message, and
the checkout halts at the beginning of SYSCON...
Can't open file 'C:\tmp\q\SYSCOM\.svn\tmp\text-base\QMClient.bas.svn-base': The
system cannot find the file specified.
Something is up with SVN I guess.
Can I use the snapshot
"http://gpl.openqm.com/downloads/snapshots/openqm-gpl-dev-2.6.6-r67.tar.gz"
instead? Will that be current enough?
Ashley Chapman
Gene Buckle
> Can I use the snapshot
> "http://gpl.openqm.com/downloads/snapshots/openqm-gpl-dev-2.6.6-r67.tar.gz"
> instead? Will that be current enough?
>
That should be fine Ashley.
Steve Bush
> message, and the checkout halts at the beginning of SYSCON...
> Can't open file
> 'C:\tmp\q\SYSCOM\.svn\tmp\text-base\QMClient.bas.svn-base':
> The system cannot find the file specified.
>
> Something is up with SVN I guess.
I have never been able to checkout scarlet into windows. I think it is
because there are both QMClient.bas and QMCLIENT.BAS files in the linux
version whereas win32 cant handle that.
Error: In directory 'D:\scarletdme\SYSCOM'
Error: Can't open file
Error: 'D:\scarletdme\SYSCOM\.svn\tmp\text-base\QMClient.bas.svn-base': The
system
Error: cannot find the file specified.
ash.c...@gmail.com
install subversion into my Linux boxes for various reasons
(conflicts/dependencies).
Under normal circumstances, it would be no problem, seeing as the
snapshot does not compile under windows (Yet).
>
>
> >
>
--
Ashley Chapman
Steve Bush
since the svn client is installed and just works.
ash.c...@gmail.com
>
> As an admin of the gpl server you can ssh into it and checkout/dev/commit
> since the svn client is installed and just works.
That will be handy. I've got a few little changes to make, but don't
want to wait until we've done the upcoming 9.6 release. I might lose
them! Presumably, there is no problem putting them into
workdevbranch1, or should I make a new branch?
Also, I'm setting up another Ubuntu box, where I can run subversion,
which will mean I can do things the "normal" way.
--
Ashley Chapman
Steve Bush
"do as you will, and let the swords of others be your guide" principle.