VC/m version control from George James

[Dawn Wolthuis]

I'm just pleased as punch at how easily VC/m got installed and up and
running for us (Ken Hall on our team working with John Murray from
George James) that I thought I'd do a little dance of joy here.

This "ad" for the George James software is completely unsolicited, by
the way. I just thought if anyone else were interested, I'd pass it
along that we are we are very happy so far with VC/m. It works with
mvb files as well as all other source code and made me more productive
right away with a little project I did yesterday. I had been
procrastinating doing a couple of file and field renames across the
s/w. I made the changes, queued them up (checked them in) until ready
to test together, deployed them all to an integration account, tested,
fixed what needed fixing, and passed pieces along to the "library" as
they passed the tests. It was very easy to track my status with all
components. That was my first significant use of the tool after the
setup of last week, and I am convinced this will help our efforts
significantly.

I'm guessing others have various homegrown solutions, but if you
happen to be looking for something, I would definitely recommend
taking a look at http://georgejames.com/

Cheers! --dawn

--
Dawn M. Wolthuis

Take and give some delight today

[oZone]

Dawn,

Can you tell me a little bit about your work flow and how VC/m fits
into it? How many developers do you have manipulating code at a time?
Are you using the transfer utility to deploy code to multiple servers?
Have you ever used any other version control software before? If so,
how does VC/m compare?

Any additional insight would be appreciated.

Thanks, Owen Mecham
Brashers Auto Auctions

> taking a look athttp://georgejames.com/

[Dawn Wolthuis]

On Wed, Jul 23, 2008 at 3:37 PM, oZone <owen....@gmail.com> wrote:
>
> Dawn,
>
> Can you tell me a little bit about your work flow and how VC/m fits
> into it?

First point is that we are writing software as a service, still in
early stages of development, so it is like VAR software, but not to be
delivered & installed (in current plans) to anyone but us, for use by
multiple organizations.

> How many developers do you have manipulating code at a time?

4-5 currently active developers, working part-time, anytime, anyplace,
no two co-located.

> Are you using the transfer utility to deploy code to multiple servers?

Not yet, but plan to in the future. Currently all accounts are on one
development box.

> Have you ever used any other version control software before?

Yes, cvs (with ant builds of java code) and pvcs in former lives, and
both while in a mgmt role, so my hands-on is sketchy. With this
project, we originally started an effort to use subversion with Cache.
There are new hooks that should make that easier, but it really
doesn't address the build process and would require us to be
distracted with a roll-our-own effort.

> If so,
> how does VC/m compare?

It is more full-featured (at least more than what I ever used) than
cvs and less-bulky than pvcs, sliding into an mv environment much more
handily than anything like pvcs. I suspect it is more like Susan J's
product (temporary memory loss on the name) in size and fit, as it was
tailored for Cache', written in Cache'.

> Any additional insight would be appreciated.

Workflow at this point is starting small with the following
namespaces, each with a separate namespace for source code. Trimming
to the essence, these accounts are roughly:

Development (MV accounts = Cache' namespaces = ADEV, with code hosted in ZDEV)
Integration Testing (VERIFY, ZVERIFY)
Demo (DEMO, ZDEMO)
Black-box Testing (BBT, ZBBT)
Alpha (ALPHA, ZALPHA)

Live account will be on another box in the future.

Each developer has an initial project in Studio, under which their
development efforts fall. They can grab a requirement (using trac for
requirements, tasks, bugs, etc), checkout code in Development, make
changes, unit test, check the code in and queue it up for integration
testing. The dev team is the integration testing team (no lectures
please ;-) and anyone, most likely the same developer, can pull it
into testing (VERIFY account), with the test data kept in somewhat
better shape than development, with regression testing performed here
(that was mostly an "in theory" statement). The code either Passes or
Fails the tests, heading into the the VC/m source code library if it
passes and back to being checked out in development if it fails. This
code can include mv basic (mvb), cache classes (cls), css (css),
javascript (js), and even image files (and we have .mvi for i-descs
too). Note that this is a very simple workflow, and considerably more
complexity is possible with this tool.

We have not yet done what I would call an actual build with the tool,
but will do so soon. It appears that we can simply give a name to a
logical set of versions for the components, such as telling it to take
the Latest version of each component and collectively call that Build
xyz. The build is not a zip file, as we had intended with subversion,
but a location name in VC/m, which could be named Build32. Then if we
decide that build 32 is the one that should be exercised in black box
testing, we can move it there, even if we now have many more builds
following 32, with an automated move of all relevant pieces installed
in the BBT account. Similarly with DEMO and ALPHA, which could be
running builds 39 and 22 respectively.

As you can tell, we are still gearing up (a phrase I continue to
reserve the right to use for quite some time regarding this project),
rather than implementing this for currently deployed software. I hope
that helps. cheers! --dawn

[Owen Mecham]

Thank you for the in depth overview. It is much appreciated!

--

Thanks,
Owen Mecham

[oZone]

I downloaded the demo, followed the installations procedures from the
user guide, but for the life of me I couldn't get the VCM routines on
the machine. I don't think the demo follows the actual installation
procedure of the full product. We'll have to give it a shot later on.

On Jul 23, 4:05 pm, "Owen Mecham" <owen.mec...@gmail.com> wrote:
> Thank you for the in depth overview. It is much appreciated!
>

> On Wed, Jul 23, 2008 at 3:54 PM, Dawn Wolthuis <dawnwolth...@gmail.com>

[Ken Hall]

The VC/m demo is designed to load on your PC with a local install of
Cache'. Loading it on your server is probably not a good idea. There
are several things that you need to change in SMP to get the demo going.

Email me directly if you need additional instructions.

Ken

[oZone]

Thanks, it's working much better on my own machine. I do have one
issue so far. When I change to the PATCHDEV or any other VC/m
namespace, I am getting an error 5880 that studio can not create the
source.control class. I am logged in as support that has the role
%All. Any ideas? I am using the latest Cache Build 2008.2.0.461.0

Thanks again.

[oZone]

I received some updated files that have allowed VC/m to work on my
machine and I must say that I have been impressed so far. It also
provides a compelling solution for program deployment.

[Jim Idle]

On Thu, 2008-07-31 at 20:02 -0700, oZone wrote:

I received some updated files that have allowed VC/m to work on my
machine and I must say that I have been impressed so far. It also
provides a compelling solution for program deployment.

I think that everyone should take perforce for a test run before making any decisions on things like this. Version control and diff tracking etc is a complex area, despite it looking seemingly easy. That's why we keep getting weak efforts like SVN appearing in the public domain.

Jim

[Dawn Wolthuis]

Wouldn't it take a lot of work just to testdrive perforce with Cache?  It doesn't come integrated with Cache out of the box, does it?

--dawn

[Jim Idle]

On Thu, 2008-07-31 at 22:10 -0500, Dawn Wolthuis wrote:

Wouldn't it take a lot of work just to testdrive perforce with Cache?  It doesn't come integrated with Cache out of the box, does it?

All source code should be in directories, not Cache globals, and you should have your application such that it creates itself from a source level set up, including dictionaries and pre-formed data - everything. So,you should be editing by checking out from something like perforce and deploying to a target environment.

However, perforce does integrate with Cache and there is a special class to do it. We used perforce in development at Intersystems and I suspect that that has not changed.

Jim

BTW - I have nothing against VC/m, I have not even seen it. I just think it will have to be bloody good to be better than perforce and that one should look before leaping. Some points you should be looking at;

- Diff revision tracking;
- Fully tracked branching;
- Forward and reverse integration between branches;
- 2 and 3 way merging;
- Transactional committed updates;
- Change lists and jobs rather than just revisions of a single source element;

Lots more you should compare, but if you are still interested in it after that list, then it will have shown itself to be a good product and worth more in-depth evaluation

[Benjamin Spead]

Dawn,

InterSystems uses Perforce internally, and Caché ships with a sample source control class which enables Perforce integration with Studio.  See:

 

http://docs.intersystems.com/cache20081/csp/documatic/%25CSP.Documatic.cls?PAGE=CLASS&LIBRARY=DOCBOOK&CLASSNAME=%25Studio.SourceControl.ISC

 

HTH,

Ben

 

---