Matt,
Hum.... An ARS "Build" concept.... What exactly would that be like?
(Which is almost part of Tim's perspective on this subject. If I can
try to put a few words in his mouth. :) )
I only see Source Control as valuable for "concurrent development
issues" in ARS, and to provide an "out of line" backup of ARS objects.
I however see it as useless for branching issues. (How do you branch
in/out a field? How do you branch in/out all related workflow that
needs updated because of the presents of the field? How do you label a
"main line" version as "in production", or some new code as "in
development"?)
As Tim points out, in ARS there really is no "local playground"
concepts. There really is no "Merge" (of ARS Object code) outside of
some, from what I have seen, limited related functionality in
Migrator. (But ver 6 gets us closer to some of those most basic
features by moving past dropping all of the data on import "in place"
of a changed form.)
So what is an ARS developer left with becomes the question.....
And as in the days of old... we are left with programmer
conventions to produce ways of doing concurrent development without
stepping on each other. Field ID ranges(variable names), Workflow
naming conventions(function/sub names), *special per person views*,
specialization of interests("Bob is the only guy who develops
application "x") and even separate ARS servers could all be used. The
trick is to make sure that all the independent "sources" of ARS
objects can be folded together without colliding with each other. (And
that can be done without an implemented SC system.) The only real
challenge is the idea that I need to change an existing object at the
same time that you are changing the same object. (Development
Concurrency)
Some programmers would look at that and say to themselves... "How
crude".... But if you know the system, and you realize that one ARS
developer can do what 10-30 C programmers can do in the same amount of
time then you have to really ask.... "Does an ARS developer really
need anything more complicated than that?"
Before I would ask for improvements to ARS "Source Control" features:
I would advocate the idea of a field registry (on each ARS
server) for use/reuse of FieldID (keyed) definitions. (Think like the
"Group" object in the admin tool, but just "current field definitions"
that could be on a expand menu on the right click on a form for a "new
field from the field registry for that server". Maybe even with the
option to related workflow triggered/related to that field to be added
to the current form as well.)
I would even suggest that exporting an "Application object"
should REQUIRE all related objects to be part of that export.
I would opt for an ARS internal "locking" implementation in the
objects without the need for an external SC system to be used. ( I
have even considered trying to develop a NULL SC system so that the
Admin tool could "talk to it" and have it do nothing on the back end.
Just so that that Admin tool can use it's own, already internal,
mechanisms to solve the concurrent development issues.)
... etc....
--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)
Solution = People + Process + Tools
Fast, Accurate, Cheap.... Pick two.
Never ascribe to malice, that which can be explained by incompetence.
On 7/14/06, Matthew White <[EMAIL PROTECTED]> wrote:
Alan,
While I agree that using VSS with Admin is touching the base -- it's
better than not using it. Especially, when you are running a project with
more than two developers --
1) Are you going to send e-mails back and forth as the
locking mechanism?
2) Have you never had the need to check a previous
version of code?
3) Have you never had the need to compare to versions
of code?
While I would like to use ANT for my build and CVS/ClearCase for my
source control it ain't [sic] going to happen any time soon with this
product... ;)
Matt White
White Consulting, Inc.
201.248.0438
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Tim Widowfield
Sent: Friday, July 14, 2006 11:54 AM
To: [email protected]
Subject: Re: Remedy integration with CVS
Matt,
I like a good back-and-forth on a Friday. I think this is a subject worth
talking about. Here's my take on the matter.
Source control is better for systems that truly have source. For example,
if I'm working on a small module in a huge C++ application at some large
outfit, I can check it out and work locally. The more sophisticated source
and version control systems can even leave my small module unlocked, with
the expectation that my changes will be blended in later.
So we can see a huge, inescapable difference already. If I check out a
module in Remedy -- let's say it's just a few filters -- I'm probably not
able to work on it locally. I'm not able to develop and test on a system
that's identical to the main trunk, except for my small changes. What I'm
working on, almost certainly, is the same development server that everybody
else is working on. The other people in my group are likely making changes
to their chunks concurrently with me. Will their changes affect what I'm
doing? Beats me.
This difference is not an insignificant distinction. When you say "source
control" to a person who's working on, say, a huge Java application project,
he or she is thinking, at least subconsciously:
1. I have a well-defined area of code that I'm working on.
2. I can compile and test it locally without affecting anyone else. I
can make a real mess of it, give up, wipe it out, and start over -- and none
of my co-workers will even know. (Except when they hear me yell "Doh!" in
my cubicle.)
3. When others make changes locally on their little bits, I'm not
affected.
4. Only after my updates have been verified and thoroughly tested by
others will my changes become part of the main trunk.
5. If my changes are deemed to be a little too wild but nonetheless
interesting, they may be placed in a branch, with the hopes that they might
be blended back into the trunk someday.
All of the above features (and many more) are intrinsic to source control.
Notice that I'm not even talking about how and when code gets put into
production. That's a whole different issue. It's all about "controlling
your source." We could approximate the above features in an AR System
development environment, but it would be very expensive. Each developer
would need his own AR Server, each identical to the current mainline trunk.
After vetting the code changes, we would need to import the objects using
Migrator. Then the whole bundle would need to be migrated to a staging
server for more testing. And finally, once the whole system has passed its
tests, we would migrate the changes to production.
Sorry to get so long-winded. It's just that I can't help thinking when
managers mandate source control and we Remedy developers say, "Yeah, we've
got that" ...well, I think we're talking about different things. What
they're really saying is they want total change control, the ultimate effect
of which is the assurance that no code changes ever get into production
without being thoroughly understood, tested, and certified. And if our
updates wreak havoc, they want us to be able to roll out our changes
immediately and restore the system to its pre-change state.
If the above is true, then I submit that integrating Visual SourceSafe with
the Admin Tool barely scratches the surface. You need to save definition
dumps constantly during the day; you need continual system backups; and most
of all you need Migrator.
[Disclaimer: I'm not trying to sell anyone on Migrator. I've always had
problems with it. I don't even enjoy using it. But in a large development
environment, you need it or something like it. It's possible that Panacea
is a better tool, but I have absolutely no experience with it. YMMV.]
Tim Widowfield
[EMAIL PROTECTED]
v: 937-878-9045
f: 937-878-9055
m: 937-369-7012
http://www.widowfield.com
----- Original Message ----
From: Matthew White
To: [email protected]
Sent: Friday, July 14, 2006 6:59:02 AM
Subject: Re: [ARSLIST] Remedy integration with CVS
** Tim,
Without getting into a back and forth. In whole, source
control is a good thing. In fact, if you do work in the financial,
insurance or pharmaceutical companies it is mandated.
While Remedy doesn't play 100% nice with MS SourceControl the good points
outway the bad points IMO. From what I am reading below (i.e., people on
vacation) it sounds like a process issue more than anything. I am not sure
who doesn't like the idea of being able to look at the differences between
code for a given object from one point to another to track down a root cause
and/or potential bug. Moreover, I enjoy having the ability to rollback to a
previous version of an object with a few clicks.
Matt White
White Consulting, Inc.
201.248.0438
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Tim Widowfield
Sent: Wednesday, July 12, 2006 10:40 PM
To: [email protected]
Subject: Re: Remdy integration with CVS
Or you could try the CVS proxy plug-in for SCC. (SCC is Microsoft's
API/protocol for SourceSafe.) I've played with it on development AR
servers, and it works OK. I've never tried it for extended periods or on
production servers. Still, it's a nice little tool...
http://www.pushok.com/soft_cvs_proxy.php
On the whole I have an ambivalent attitude toward source control on ARS.
It gives other development groups and managers (the PHBs) the mistaken
impression that we actually have "source." In reality, we have the opposite
of source code -- we're storing exported, rendered definition files. There
is no AR preprocessor. There is no AR compiler.
I will grant you that it's nice to be able to lock out code that's under
construction. However, I've experienced two kinds of events in which
SourceSafe really gets in the way of productive work. First, I've been
stuck with AR objects that are checked out (locked) by people who left on
vacation. That's a pain, but not a real killer. Second, I've been on
projects where SourceSafe has crashed. There's a good reason why
Microsoft's internal development teams don't use SourceSafe... It isn't
reliable and it doesn't scale. At least this was the state of affairs
throughout the late 90s and the early 00s. If SourceSafe has recently
gotten more reliable and scalable, that's nice. (But I kinda doubt it... I
mean, consider the "source.")
Tim Widowfield
[EMAIL PROTECTED]
v: 937-878-9045
f: 937-878-9055
m: 937-369-7012
http://www.widowfield.com
----- Original Message ----
From: Matthew White
To: [email protected]
Sent: Wednesday, July 12, 2006 9:03:33 PM
Subject: Re: [ARSLIST] Remdy integration with CVS
**
Balaji,
Good luck! ;)
In short, you would have to export each object into a def
file and Checkout/Commit via command line or IDE (i.e., WinCVS). This is a
place where Remedy/BMC just falls short.
Matt
White Consulting, Inc.
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Balaji
Sent: Wednesday, July 12, 2006 8:01 AM
To: [email protected]
Subject: Remdy integration with CVS
**
Hello,
I want to integrate remedy with CVS. Has any one does this integration
before and can you pls share details as how to go about it.
regards
Balaji
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
