Source control

[NebulaTonyG]

(testing the water here)

I'm curious about what measures jBASE users have in place for
controlling their source code. Do you have a custom interface to
cvs/rcs/sccs or similar? Does your source control system have a
rollback mechanism that works with jBASE? Are you concerned about
HIPAA, Sarbanes-Oxley, or other government regulation compliance (for
your specific country or countries in which you do business)?

A solution for this could be made available for jBASE developers if
there were demand. If there are already standard solutions that people
use then we probably don't need a jBASE-specific product for doing
this.

So I'm sincerely interested in hearing what people are doing, but if
there are no standards then I welcome inquiries.

Thanks!
Tony Gravagno
Nebula R&D, jBASE Distributor
TG@ removethisNebula-RnD .com

[Clif Bristol]

Since we are windows only based, we use Visual Source Safe. I've written My own interface to it to facilitate version builds and rollbacks so I wouldn't have a need for another source control program....Thanks

[Mark Hogden]

We have been using Perforce for our development since Jan 01, it's also
installed and in use at numerous user sites. We have yet to use all that
Perforce has to offer, such as branches, but we cannot imagine doing
development without it.

For those sites where SOX is in full force, we use two perforce users, one
for development and one for the live side. When the users are happy with the
development code, the live user synchs to the appropriate changelist
thusupdating the live code and runs our routine which takes the changelists,
does the compiles and makes the other necessary file updates (thanks Tom).

Triggers on the jBase directories handle check-outs automatically. It's just
about as nice as it can be and it's free for the first two 2 client
licenses.

Mark Hogden
Proco Inc.

-----Original Message-----
From: jB...@googlegroups.com [mailto:jB...@googlegroups.com] On Behalf Of
NebulaTonyG
Sent: Saturday, September 24, 2005 3:50 PM
To: jBASE
Subject: Source control

[Kevin Powick]

> -----Original Message-----
> From: jB...@googlegroups.com [mailto:jB...@googlegroups.com]On Behalf Of
> Mark Hogden
> Sent: September 24, 2005 7:32 PM
> To: jB...@googlegroups.com
> Subject: RE: Source control
>
>
>
> We have been using Perforce for our development since Jan 01, it's also
> installed and in use at numerous user sites. We have yet to use all that
> Perforce has to offer, such as branches, but we cannot imagine doing
> development without it.

We use Perforce as well. Great product.

--
Kevin Powick

[Gary Calvin]

We use Subversion. It seems to do everything we need.

-Gary-

[Kevin Doiron]

I was looking for a similar product, and was actually going to develop
something myself. I'm not worried about any legislative requirements
(yet) - my concern is more about keeping track of development projects
and ensuring programmers don't accidentally kill each other's work.

Where does one find these two products (I especially like the idea of
Perforce, as it is free).

Thank you.

Kevin Doiron

[Mark Hogden]

www.perforce.com

Free to use for the 'first two' clients.

The source that you are looking to control needs to be stored in directories
and not hashed files.

Mark Hogden

-----Original Message-----
From: jB...@googlegroups.com [mailto:jB...@googlegroups.com] On Behalf Of

[David Grenfell]

My solution is to not put my source code on client machines. Some of the
debugger messages (if any) are a little criptic, but at least I can sleep at
night, knowing nobody is going to copy.

GRENDATA COMPUTER SYSTEMS

David Grenfell
Proprietor

[Jim Idle]

Kevin,

At first glance, a source code control product looks like a pretty easy
thing to write, until you start looking in to the change tracking
aspects. I would not recommend going down that route!

www.perforce.com is where you get the perforce trial/free versions. You
should note that it is 'free' basically for one user on two different
client machines or two users on the same machine. After that it is
reasonably priced for what it is, but you might find it prohibitive if
you were 'giving it away' with your product.

CVS might be just as good for some kind of embedded solution as it is
entirely gratis; though it has the wrong tracking model if you ask me,
whereas perforce tracks things more along the lines you would
intuitively expect.

Mark: Rather than using two perforce servers, you would probably find
that branches do what you need for developer/release type mechanisms,
though of course you could end up having to PAY for some licenses to do
this ;-). The advantage of branches are that they track all changes made
to any set of the source code, and you can therefore propagate things
like patches to many branches. Then you can label a particular branch as
say "Rel 4.5" and so on.

Security concerns are greatly alleviated with the token based logins
that the latest perforce servers use. Much better than clear text of
course. You can also run the server across secure socket layers via ssh
and so on.

The source code branches can be authorized on a user or client (usually
machine) level such that one person can do anything they like, another
can just read and yet another cannot see a particular branch at all. You
can also do things like allow deletes (for instance documents etc) but
not allow obliterates, which means that you can delete it from the view
of the source but the document is just marked as deleted and can be
recovered anyway.

However didn't SOX just mean that large companies stopped writing
anything down and became even more inefficient and useless than they
already were? Or am I just getting more cynical in my middle age? ;-)

Jim

PS: This email will self-destruct in 5 seconds. . . .

[Jim Idle]

I think most people's solution is to mangle the source code by deleting
all the comments... or is it just that that's what it looks like in the
first place? ;-)

Something like perforce can help a lot here though, in that you don't
ship a copy of the source code anywhere, but can trivially sync it up to
your client's machine, debug a problem, fix it on their machine,
recompile, test, then check in the changes directly back to your real
source code and delete the local source. This means you will always get
the actual fix you gave a customer tracked properly in your source code.


We used this approach extensively at jBASE. Thus we could go to
Montpelier, South of France and port to OS390 and OS400 at IBM's
facilities and never worry that we had forgotten the source code or
missed a patch and so on. Hence, Greg and I are immensely grateful to
Perforce for allowing us to spend about 9 months in the South of France
- it even works on the beach and in the bar - especially well in the bar
on the beach. The only downside being that while in France I started
smoking again as the dirty non-smokers are frowned upon there ;-).

You too therefore could spend time in the South of France just by using
perforce.

Sincerely,

Carlton Sheets.

PS: Perforce may be hazardous to your health and cause lung cancer,
breathing difficulties and other problems. Pregnant women should not use
perforce. Perforce will track changes to your comments revealing that
you didn't really understand what you were doing and result in you being
fired.

> -----Original Message-----
> From: jB...@googlegroups.com [mailto:jB...@googlegroups.com] On Behalf
Of

[Tony G]

David Grenfell wrote:
> My solution is to not put my source code on client
> machines. Some of the debugger messages (if any) are a
> little criptic, but at least I can sleep at night,
> knowing nobody is going to copy.
>
> GRENDATA COMPUTER SYSTEMS
>
> David Grenfell
> Proprietor

That's an interesting perspective. One of the business trends these days
is for companies to claim that they are "open source" by leaving their
proprietary source code open for view on client systems. The code is
licensed, can't be moved, and all modifications must be returned to the
vendor - and I've seen vendors boast at only charging about $15k for the
special service of providing source to their clients, something many MV
VARs have done for over 20 years. Their slant allows them to look
progressive and steal business from MV guys who are now more protective of
their software. :)

BTW, source "control" doesn't mean keeping it from your clients, it means
allowing you to better control it yourself.

T

[Tony G]

Mark Hogden wrote:
> www.perforce.com
> Free to use for the 'first two' clients.
>
> The source that you are looking to control needs to be
> stored in directories and not hashed files.

> Kevin Doiron wrote

> I was looking for a similar product, and was actually
> going to develop something myself.

Thanks all for your comments guys. It seems there may be a little room for
a jBASE-specific solution. Here's my angle:

PRC from SJPlus is a MV-based software management system. Have a look at
the feature set which does work with hashed files and is well beyond
perforce or custom cvs ditties.
http://sjplus.com/what_does_it_all_mean.cfm

But PRC doesn't run over jBASE ... yet. This is because PRC is based over
the dreaded SB+. The OSMOSiS 4GL includes a high-quality SB+ converter
_and_ it runs over jBASE. As a new Distributor for OSMOSiS and jBASE, it
seems to me some multi-developer jBASE shops might be looking for some real
software management tools, and if we can drum up some demand it may be
worth doing a conversion of PRC for you.

Having more products like this available in the jBASE market will help to
make jBASE more marketable, and more approachable by MV VARs who could be
on the fence. My goal is to get more utilities and apps to convert to
jBASE, which is good for everyone here.

So if you're interested in PRC, please feel free to contact Susan Joslyn at
SJ+, CC to me if you'd like. And if you know of any poor souls who are
running SB+ and they want to migrate to jBASE, please feel free to refer
them to me.

Susan Joslyn: sales@ removethisSJPlus.com

Thanks and regards,
Tony Gravagno
Nebula Research and Development
jBase@ removethisNebula-RnD.com

[Clif Bristol]

The one thing that would help me is for a mod to the catalog routine that will record a: Version, Build No., and Comment. Then build something into jshow that will display this info. I've built my own front end to the catalog routine that kind of does this but its a bit clunky. Ideally this info should be built into the libdef file.

-----Original Message-----
From: jB...@googlegroups.com [mailto:jB...@googlegroups.com]On Behalf Of

Tony G
Sent: Monday, September 26, 2005 2:22 PM
To: jB...@googlegroups.com
Subject: RE: Source control

[Ross Ferris]

I remember years ago writing a pre-compiler that simply inserted a
standard line of text on line 2 of a program along the lines of :

VERSIONFLAG = "XYZ - compiled 99/99/99 @ 99:99 by Fred for Job 123"

Nice an obvious from a debugger, or even a hex dump

[Clif Bristol]

Easy enough for executables not so good for subroutines and functions which need the exact set of parameters passed and the number of parameters are different from one sub to another.

[Jim Idle]

We do generate this in the C cource that is sent to the C compiler, if
you use jbc -S or jcompile -S and inspect the generated .j file:

/* (1) Time and date of creation of object */

0x6a,0x42,0x43,0x20,0x6d,0x61,0x69,0x6e,0x28,0x29,0x20,0x76,0x65,0x72,0x
73,0x69, /* jBC main() versi */

0x6f,0x6e,0x20,0x34,0x2e,0x31,0x20,0x4d,0x6f,0x6e,0x20,0x53,0x65,0x70,0x
20,0x32, /* on 4.1 Mon Sep 2 */

0x36,0x20,0x31,0x31,0x3a,0x33,0x31,0x3a,0x34,0x30,0x20,0x32,0x30,0x30,0x
35,00, /* 6 11:31:40 2005. */

Now, I just cant remember what you do to bring this information out at
runtime. It is probably something like SYSTEM(10nn). Perhaps someone
could look this up.

However using the UNIX (or Cygwin) command strings on the .o or .obj
file or the .exe or executable that is generated will give you:

jsh jimi ~\lib\objdir -->strings S.obj
c:\iscsrc\Users\jimi\BASIC_1.obj8
!Microsoft (R) Optimizing Compiler
jBC S source file BP
Austin Powers
TEST
jBC S version 4.1 Fri Sep 09 09:19:14 2005
SUBROUTINE S

Blimey! What's Austin Powers doing in there? Who does a thing like that
these days... I ask you? I didn't go to Evil Programming school for
that! <cough>

So, if you do:

sh jimi ~\bin -->strings TEST2.exe |grep "^jBC"
jBC main() source file BP
jBC main() version 4.1 Mon Sep 26 16:28:14 2005

You will get something akin to what you wish for.

Jim

[Jim Idle]

JED BP FRED

File BP , Record 'FRED'
Command->
0001 SUBROUTINE FRED(A,B,C)
0002
0003 CRT G
0004
0005 RETURN

<Esc>FIBC

BASIC BP FRED
FRED
Warning: Variable G is never assigned!
BASIC_2.c
Source file FRED compiled successfully
CATALOG BP FRED
FRED
Object FRED cataloged successfully
Library c:\iscsrc\Users\5.1.mv\kernel\cachebuild\lib\lib0.dll rebuild
okay

sh jimi ~\lib\objdir -->strings FRED.obj
?c:\iscsrc\Users\5.1.mv\kernel\cachebuild\lib\objdir\BASIC_2.obj8
!Microsoft (R) Optimizing Compiler
jBC FRED source file BP
Austin Powers
FRED
jBC FRED version 4.1 Mon Sep 26 16:34:04 2005
SUBROUTINE FRED
A t=p #=0
B t=p #=1
C t=p #=2
G t=l #=2


You can see that the subroutine parameters are conveniently marked with
t (for type) = p for parameter.

Jim

Ps: Though there are similar things in jBASE 3.x you will need to
experiment to locate them. The stuff above is jBASE 4.1

> -----Original Message-----
> From: jB...@googlegroups.com [mailto:jB...@googlegroups.com] On Behalf
Of
> Clif Bristol
> Sent: Monday, September 26, 2005 4:27 PM
> To: jB...@googlegroups.com
> Subject: RE: Source control
>
>

> Easy enough for executables not so good for subroutines and functions
> which need the exact set of parameters passed and the number of
parameters
> are different from one sub to another.
>

[Clif Bristol]

Not sure this is quite what I was looking for but let me give you one of my "real world" examples and you can tell me how it applies.

I'm on a Windows 2000 platform and I use Visual Source Safe. VSS will keep track of the version number and whenever I do a new build I label the project in VSS with that build number such as 3.1.004(where 3 is major release, 1 is the minor, and 004 is the build number). Now I go to do a new build on the subroutine INVOICE.ENTRY.b. The build label is 3.1.004 and the vss version number is 6. How would I get this info into a file that can be retrieved from something like SYSTEM(10nn)?

-----Original Message-----
From: jB...@googlegroups.com [mailto:jB...@googlegroups.com]On Behalf Of
Jim Idle
Sent: Monday, September 26, 2005 4:32 PM
To: jB...@googlegroups.com
Subject: RE: Source control

We do generate this in the C cource that is sent to the C compiler, if
you use jbc -S or jcompile -S and inspect the generated .j file:

/* (1) Time and date of creation of object */

0x6a,0x42,0x43,0x20,0x6d,0x61,0x69,0x6e,0x28,0x29,0x20,0x76,0x65,0x72,0x
73,0x69, /* jBC main() versi */

0x6f,0x6e,0x20,0x34,0x2e,0x31,0x20,0x4d,0x6f,0x6e,0x20,0x53,0x65,0x70,0x
20,0x32, /* on 4.1 Mon Sep 2 */

0x36,0x20,0x31,0x31,0x3a,0x33,0x31,0x3a,0x34,0x30,0x20,0x32,0x30,0x30,0x
35,00, /* 6 11:31:40 2005. */

Now, I just cant remember what you do to bring this information out at
runtime. It is probably something like SYSTEM(10nn). Perhaps someone
could look this up.

However using the UNIX (or Cygwin) command strings on the .o or .obj
file or the .exe or executable that is generated will give you:

jsh jimi ~\lib\objdir -->strings S.obj
c:\iscsrc\Users\jimi\BASIC_1.obj8

!Microsoft (R) Optimizing Compiler
jBC S source file BP
Austin Powers

TEST
jBC S version 4.1 Fri Sep 09 09:19:14 2005
SUBROUTINE S

Blimey! What's Austin Powers doing in there? Who does a thing like that
these days... I ask you? I didn't go to Evil Programming school for
that! <cough>

So, if you do:

sh jimi ~\bin -->strings TEST2.exe |grep "^jBC"
jBC main() source file BP
jBC main() version 4.1 Mon Sep 26 16:28:14 2005

You will get something akin to what you wish for.

Jim

[Jim Idle]

No you can't do that I am afraid. All you can do is see if the object
code was compiled after the version you want was checked in to see if it
is the latest object code.

[Kevin Powick]

> -----Original Message-----
> From: jB...@googlegroups.com [mailto:jB...@googlegroups.com]On Behalf Of
> Clif Bristol
> Sent: September 26, 2005 7:46 PM
> To: jB...@googlegroups.com
> Subject: RE: Source control
>

> I'm on a Windows 2000 platform and I use Visual Source Safe.

No answer to your question, but I think you should seriously consider
another SCM product.

I used VSS for a while, but more than once I ended up with corrupted data.
Also, IIRC, it's much too easy in VSS to accidentally, permanently delete
your files.

I've heard that Microsoft doesn't even use it to manage their code. Has it
even been updated since 6.x?

--
Kevin Powick
Trident Information Systems

[Tony G]

Clif Bristol wrote:
> I'm on a Windows 2000 platform and I use Visual Source

> Safe....

Everyone is talking about saving code with a version#. Does anyone have
any kind of rollback plan for code in development or code that's already
been deployed? What about check-in/out? Problem management? Etc?
Obviously I'm angling at features provided by PRC but I'm sincerely curious
about if or how some larger shops handle these things.

I'll make that more broad in scope - has anyone aware of a software
management solution that will allow us to do proper management of projects
with pieces in hashed files, web sites (html, aspx), object code (jar, dll,
exe), etc?

Thanks.
T

[Clif Bristol]

Been using vss 6.0 for over 2 years without any corruption.

I don't give users privileges to permanently delete files even my own user id. If I need to permanently delete a file I have to login as the administrator.

I understand that many prefer other SCM products but what I do like about vss is you have access the vss object in vb and .net so you can write your own interface to it, which I did. I wrote my own interface for when we do builds. It labels every file with a build number so I can always go back and re-build any previous builds.

[Kevin Powick]

> -----Original Message-----
> From: jB...@googlegroups.com [mailto:jB...@googlegroups.com]On Behalf Of
> Tony G
> Sent: September 26, 2005 8:12 PM
> To: jB...@googlegroups.com
> Subject: RE: Source control

> I'll make that more broad in scope - has anyone aware of a software
> management solution that will allow us to do proper management of projects
> with pieces in hashed files, web sites (html, aspx), object code
> (jar, dll, exe), etc?

There are many tools, suites, utilities for complete software management.

Perforce alone can do most of this, except the hashed file stuff.

The question that comes to mind is why would you want to maintain source
code in MV hashed files? Right away it limits your toolbox (editors, file
comparison tools, merging, printing, formatting, etc.)

You have everything to gain and, IMO, nothing to lose if you keep MV source
items as files in a directory of the native OS. You can even continue to
use ED if so inclined, so there's really no reason to use MV hashed files
for source.

I do appreciate the MV data model, but see little point in trying to
create/use tools specifically designed for MV. The focus should be on
making MV work with the greater number of vastly superior tools that are
already out there. I believe jBASE was borne from this philosophy and
completely understand why, IIRC, the original plan did not include a query
processor (today's jQL) such as Access/English.

Let MV vendors focus on making it a better database. No need to re-invent
web servers, SCM, fax servers, etc. By doing such re-invention, isn't one
supporting what we've all heard for years, that MV isn't compatible with
many mainstream technologies?

--
Kevin Powick

[Tony G]

Kevin Powick wrote:
> Let MV vendors focus on making it a better database.

None of this came from any of the MV vendors, but if you mean
VAR/resellers, I get your drift.

> No need to re-invent web servers, SCM, fax servers, etc. By
> doing such re-invention, isn't one supporting what we've
> all heard for years, that MV isn't compatible with many
> mainstream technologies?

Full agreement but in this case perhaps the wrong argument. The reason I
started looking at this was that it seems that we don't have an affordable
all-in-one mainstream product for software management. Here's a product
that does mainstream features plus more, plus it supports hashed files
besides. Is the fact that a product supports hashed files a stigma? If it
runs with jBASE, it could be sold to entirely non-MV shops bundled as an
embedded application. All this does is make jBASE more "mainstream" than
before.

There is value for many companies in buying a single-source solution,
rather than spending a lot of time hobbling together freeware into
something unmaintainable by anyone but the hobbler - as many of us do. PRC
is one of the few products that can be proposed to new VARs and end-users
alike as a compelling reason to adopt an MV platform in the first place,
especially larger sites.

It seems questions are coming up all over MV-land about how to properly do
source control, and there are no consistent answers outside of
do-it-yourself with freeware. In the big picture that just doesn't seem
like the right business response from anyone with a vested interest in this
business.

Hey Jim - what are people using with Cache'?

T

[Kevin Powick]

> -----Original Message-----
> From: jB...@googlegroups.com [mailto:jB...@googlegroups.com]On Behalf Of
> Tony G
> Sent: September 26, 2005 10:37 PM
> To: jB...@googlegroups.com
> Subject: RE: Source control

> Here's a product
> that does mainstream features plus more, plus it supports hashed files

Supporting hashed files is not enough of a "plus" to put this product head
and shoulders above the rest. Especially since the rest will
control/version your source if you simply take advantage of an already
existing feature in your MV database -- The ability to store source code in
OS files.

> Is the fact that a product supports hashed files a stigma?

No, just not a compelling feature.

> If it runs with jBASE, it could be sold to entirely non-MV shops bundled
as an
> embedded application. All this does is make jBASE more "mainstream" than
> before.

I think that's a bit of a stretch, but who knows?

> There is value for many companies in buying a single-source solution,

There can be.

> rather than spending a lot of time hobbling together freeware into
> something unmaintainable by anyone but the hobbler

Such an approach was not suggested. Today, the price of software often does
not correlate to its value.

> PRC
> is one of the few products that can be proposed to new VARs and end-users
> alike as a compelling reason to adopt an MV platform in the first place,
> especially larger sites.

I don't think most people consider the underlying data storage technology in
their SCM software in such a way as to make them consider any particular
database whatsoever. Also, like many MV databases themselves, this PRC
product is obscure and quite poorly presented on the company website.

> It seems questions are coming up all over MV-land about how to properly do
> source control, and there are no consistent answers outside of
> do-it-yourself with freeware.

Untrue. The answer is the same for anyone from any software group/platform.
Do some research on the popular SCM tools. Perhaps download a few to see
what one you like best, then use it. Integration with your MV platform
should be quite simple.

> In the big picture that just doesn't seem
> like the right business response from anyone with a vested
> interest in this business.

While the MV world may seem to struggle to compete with other database
technologies, I think your take on SCM as an illustration of lack of MV
vendor or community support is a bit dramatic.

--
Kevin Powick

[Tony G]

Kevin Powick wrote:
> While the MV world may seem to struggle to compete with
> other database technologies, I think your take on SCM as
> an illustration of lack of MV vendor or community support
> is a bit dramatic.

You know me Kev, for me the conversation is often more fun than the topic
itself. Thanks for the exchanges.

T

[T.Turkington]

Being a Perforce user I'm in approximately 99.99% agreement with you Kevin,
but there's a hair of me that would appreciate being able to bypass folders
and use hash files. Mainly this is because we (Proco) maintain FILE.SPECS
(Data Dictionaries) and a screen descriptor file (position/length/input
options) via Perforce. I'm sure if push came to shove we could reorganize
the way we store this info, but right now our FILE.SPECS are located in a
single folder, and the screen descriptors another, each with 8000+ and 5000+
items respectively. Unfortunately Windows doesn't do a very good job
handling folders with this many items; and if you're using p4win and need to
search the folder, or just trying to open the folder's parent folder via
explorer, expect to wait. As I said, I'm sure we could change the folder
structure if the OS 'slowness' with these folders was a big enough
nuissance. Reality is it's borderline... Enough to annoy but not enough to
make me get off my butt and do something about it. Nor, at this point in
time do I imagine us changing sccs to get this feature.

Tom

-----Original Message-----
From: jB...@googlegroups.com [mailto:jB...@googlegroups.com]On Behalf Of

[Jim Idle]

Microsoft actually use perforce. However I believe that they took a
version of it and made it their own in-house thing, calling it something
else.

Perforce can convert VSS databases I belive.

Jim

> -----Original Message-----
> From: jB...@googlegroups.com [mailto:jB...@googlegroups.com] On Behalf
Of
> Kevin Powick
> Sent: Monday, September 26, 2005 5:12 PM
> To: jB...@googlegroups.com
> Subject: RE: Source control
>
>

> > -----Original Message-----
> > From: jB...@googlegroups.com [mailto:jB...@googlegroups.com]On
Behalf Of

[Jim Idle]

Obviously something written with multivalue in mind could deal with
elements of a project stored in multi-value format.

However, version and source control in general is a thorny problem. I
have not seen anything that handles multiple edits and merges better
than perforce. This is the basis of any source control system and is
usually the biggest problem for larger development groups. From this
basic source control, you create your version control (i.e. the version
of the whole thing rather than an individual file) and on top of this
you need change control (the process of change rather than the code
itself).

I personally never keep things in hashed files as they are too difficult
to deal with as part of the application source code. The best way is to
keep everything in perforce with one build process that produces things
like DICT files and pre-stored data files as part of the build, then
optionally packages it up.

I know that you are pointing out that PRC has the ability to deal with
some of these MV specific issues, but I would need some serious
convincing that it could handle source code diff, merge, multiple
check-out, resolve and code branch tracking and integration, and for 50
or 60 (or many more) developers - this is a very tricky thing to get
right. Just check out some of the published algorithms for file-diff for
instance.

Apart from storing things in hashed files directly as part of the
development process, perforce deals with everything else extremely well.
Configuration management is a process above source code control. It is
possible that an interface to hashed files could be provided too I
suppose but I have never seen the need. I think hashed files are for
deployment and not for storing the originating files.

Bug tracking and reporting and so on is handled via an interface to such
systems that is provided gratis. For instance you can set up an
interface to bugzilla in half a day or so.

Jim


> -----Original Message-----
> From: jB...@googlegroups.com [mailto:jB...@googlegroups.com] On Behalf
Of
> Tony G
> Sent: Monday, September 26, 2005 5:12 PM
> To: jB...@googlegroups.com
> Subject: RE: Source control
>
>

> Clif Bristol wrote:
> > I'm on a Windows 2000 platform and I use Visual Source

> > Safe....
>
> Everyone is talking about saving code with a version#. Does anyone
have
> any kind of rollback plan for code in development or code that's
already
> been deployed? What about check-in/out? Problem management? Etc?
> Obviously I'm angling at features provided by PRC but I'm sincerely
> curious
> about if or how some larger shops handle these things.
>

> I'll make that more broad in scope - has anyone aware of a software
> management solution that will allow us to do proper management of
projects
> with pieces in hashed files, web sites (html, aspx), object code (jar,
> dll,
> exe), etc?
>

> Thanks.
> T

[Jim Idle]

No need to change if it works for you of course. Such interfaces from VB
etc are also available for most other SCMs though of course.

Jim

> -----Original Message-----
> From: jB...@googlegroups.com [mailto:jB...@googlegroups.com] On Behalf
Of
> Clif Bristol
> Sent: Monday, September 26, 2005 5:22 PM
> To: jB...@googlegroups.com
> Subject: RE: Source control
>
>

> Been using vss 6.0 for over 2 years without any corruption.
>
> I don't give users privileges to permanently delete files even my own
user
> id. If I need to permanently delete a file I have to login as the
> administrator.
>
> I understand that many prefer other SCM products but what I do like
about
> vss is you have access the vss object in vb and .net so you can write
your
> own interface to it, which I did. I wrote my own interface for when we
do
> builds. It labels every file with a build number so I can always go
back
> and re-build any previous builds.
>

> -----Original Message-----
> From: jB...@googlegroups.com [mailto:jB...@googlegroups.com]On Behalf
Of
> Kevin Powick
> Sent: Monday, September 26, 2005 5:12 PM
> To: jB...@googlegroups.com
> Subject: RE: Source control
>
>
>

> > -----Original Message-----
> > From: jB...@googlegroups.com [mailto:jB...@googlegroups.com]On
Behalf Of

> > Clif Bristol
> > Sent: September 26, 2005 7:46 PM
> > To: jB...@googlegroups.com
> > Subject: RE: Source control
> >
>

> > I'm on a Windows 2000 platform and I use Visual Source Safe.
>
> No answer to your question, but I think you should seriously consider
> another SCM product.
>
> I used VSS for a while, but more than once I ended up with corrupted
data.
> Also, IIRC, it's much too easy in VSS to accidentally, permanently
delete
> your files.
>

> I've heard that Microsoft doesn't even use it to manage their code.
Has
> it
> even been updated since 6.x?
>

[Clif Bristol]

Good point Tom, this is also an issue for me as we also have screen descriptors, file dicts, and procs. What we do on our development systems and in vss is keep them as directory files. When we do a customer build we convert them to hash files. There are a few inconveniences with this in that you have to do a binary copy from directory files to hashed to avoid turning characters such char(10) to an attribute mark.

-----Original Message-----
From: jB...@googlegroups.com [mailto:jB...@googlegroups.com]On Behalf Of
T.Turkington
Sent: Tuesday, September 27, 2005 7:38 AM
To: jB...@googlegroups.com
Subject: RE: Source control

Being a Perforce user I'm in approximately 99.99% agreement with you Kevin,
but there's a hair of me that would appreciate being able to bypass folders
and use hash files. Mainly this is because we (Proco) maintain FILE.SPECS
(Data Dictionaries) and a screen descriptor file (position/length/input
options) via Perforce. I'm sure if push came to shove we could reorganize
the way we store this info, but right now our FILE.SPECS are located in a
single folder, and the screen descriptors another, each with 8000+ and 5000+
items respectively. Unfortunately Windows doesn't do a very good job
handling folders with this many items; and if you're using p4win and need to
search the folder, or just trying to open the folder's parent folder via
explorer, expect to wait. As I said, I'm sure we could change the folder
structure if the OS 'slowness' with these folders was a big enough
nuissance. Reality is it's borderline... Enough to annoy but not enough to
make me get off my butt and do something about it. Nor, at this point in
time do I imagine us changing sccs to get this feature.

Tom

-----Original Message-----
From: jB...@googlegroups.com [mailto:jB...@googlegroups.com]On Behalf Of
Kevin Powick
Sent: Monday, September 26, 2005 6:22 PM
To: jB...@googlegroups.com
Subject: RE: Source control

> -----Original Message-----
> From: jB...@googlegroups.com [mailto:jB...@googlegroups.com]On Behalf Of

> Tony G
> Sent: September 26, 2005 8:12 PM
> To: jB...@googlegroups.com
> Subject: RE: Source control

> I'll make that more broad in scope - has anyone aware of a software
> management solution that will allow us to do proper management of projects
> with pieces in hashed files, web sites (html, aspx), object code
> (jar, dll, exe), etc?

[Jim Idle]

> -----Original Message-----
> From: jB...@googlegroups.com [mailto:jB...@googlegroups.com] On Behalf Of
> Tony G
> Sent: Monday, September 26, 2005 7:37 PM
> To: jB...@googlegroups.com
> Subject: RE: Source control
>
>
> Kevin Powick wrote:
> > Let MV vendors focus on making it a better database.
>

> business.
>
> Hey Jim - what are people using with Cache'?
>
> T

Well, I think that Kevin expressed the philosophy of jBASE, or at least its raison d'etre very well. That is the vendor position for it if you like. However producing a product WITH jBASE allows you to come in at different angles, such as producing embedded products as you suggest. In the case of SCM though I would be very impressed if an MV based product could compete with the likes of perforce.

The idea of jBASE then was that it WASN'T PICK ;-). I.e. you took all the good bits of your application and produced a native application that used whatever it needed from the software pooliverse.

Cache is completely different and is more akin to the standard MV environment, except perhaps that its integration with the world is more comprehensive because, basically, we have more money to make it so! Cache is about being a database and about providing a data model that competes against Oracle, DB2 and the standard SQL model of the world. It does provide SQL models of course, but that isn't the only answer.

Quite frankly Intersystems have been saying and doing what bunches of people in the MV world have been asking for: Promoting a data model and approach rather than trying to hide it. jBASE was the other way around, I said that if you could not compete with the MV model, then let's provide something that gets the best of an application moving in that world. I didn't have the money to market the system in the "real" world directly. That's what Intersystems have done with Cache though, and why I see it as being extremely good for MV, despite the fact that ones first reaction is "Why do we need ANOTHER version of the mV model?". The answer is that we don't of course, what we need is a market player that will go and promote the base platform such that when you take your app into the IT director, he says "Oh yeah - Cache, that's the fastest growing embedded system to there right now isn't it?" and finds himself staring at the advertisement in xyz magazine.

So, all the pre-amble is to set the stage for an answer Tony ;-). Basically, Caché has a development IDE to which we have added capabilities for MV directly. As part of its set up it integrates with source code control systems, which could be Perforce, VSS or a bunch of others of course.

There are lots of add-on products for software configuration and so on, however the game at Intersystems is to try and provide you with [at least] a reasonable version of everything you need. So, out of the box, you get (or in some cases will get, when I have finished typing it in) an IDE, Web development, SQL Engine, Multivalue Engine (actually these are just two aspects of the same thing, which means that both benefit from advances in the other), MQ Series integration, Java classes and so on.

There is also an additional product written within Cache itself, which is more of an Integration engine, such that it can take a message from anything you have a plug-in for (MQ Series, messages queues, databases etc) and massage and translate it into anything else you have a plug-in for. Simple explanation of course - much more on the web sites. But your MV systems will be able to plug-in to this and it is very powerful. For instance anybody that takes data feeds from something or other (Debt collection for instance?) may well use this.

Our intention is that any add-on product out there in MV right now will be able to work with any other Cache product/add-in. However, here we are promoting our database and not the idea that you can place Oracle underneath the app (there are SQL gateways to other engines, but we want your data in Cache!)

Some of the integrations that have been possible have allowed me to experiment with extensions to BASIC, some of which many of you will like very much. For instance, a multi-dimensional array in Cache is much more comprehensive than an MV one. For a start, there can be any number of levels to it, and each level is indexed not just by a number, but by a string key as well. So, I thought we would add this capability to MV BASIC and allow such animals to be stored and retrieved from the native Cache database (rather than a simple hashed file model). Something like this (I have not set the syntax in stone yet):

Dim AccountVar As CacheGlobal

AccountVar("1964","July",14,"Balance")=500.45

This kind of syntax creates a variable which is automatically stored in the database (a Global is the equivalent of a file), and can be mapped into SQL tables and so on. In fact your MV data files are just constrained versions of these globals, whereby there is one subscript, being the Item ID, whose data value is the MV item (complete with AM and VM and SVM etc).

Further the runtime engine in Cache has object capabilities built in, so why not be able to produce and object directly from the DICT definition and use that directly in MV, something akin to:

: CREATE-OBJECT DICT MyFile AS %MV.Data.MyFile
Class '%MV.Data.MyFile' created in namespace "%SYS"


Dim myObject as New %MV.Data.Myfile

OPEN "MyFile" To Fdesc ELSE ABRT 201, "MyFile"
myObject.load(Fdesc,"ItemID")

myObject.Name = "Fred"
... etc
MyObject.Store(Fdesc, "ItemID")


And so on and so forth.

Sorry about the long reply that was only vaguely relevant to your question, but... Onwards and upwards!!

Jim

[Kevin Powick]

> -----Original Message-----
> From: jB...@googlegroups.com [mailto:jB...@googlegroups.com]On Behalf Of
> Jim Idle
> Sent: September 27, 2005 11:15 AM
> To: jB...@googlegroups.com
> Subject: RE: Source control

> have not seen anything that handles multiple edits and merges better
> than perforce.

Have you ever looked at BitKeeper (http://www.bitkeeper.com/)? Any comments?

I've heard some good things about it. They claim to have advantages over
Perforce, but who knows when they did their comparisons.

I doubt I would switch now, but always interested in what's going on out
there.

--
Kevin Powick

[Clif Bristol]

Hope its an easy conversion from jBASE to Cache

-----Original Message-----
From: jB...@googlegroups.com [mailto:jB...@googlegroups.com]On Behalf Of
Jim Idle
Sent: Tuesday, September 27, 2005 8:51 AM
To: jB...@googlegroups.com
Subject: RE: Source control

> -----Original Message-----
> From: jB...@googlegroups.com [mailto:jB...@googlegroups.com] On Behalf Of

> Tony G
> Sent: Monday, September 26, 2005 7:37 PM

> To: jB...@googlegroups.com
> Subject: RE: Source control
>
>