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
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail Beta.
__20060125_______________________This posting was submitted with HTML in
it___
__20060125_______________________This posting was submitted with HTML in
it___
__20060125_______________________This posting was submitted with HTML
in it___ __20060125_______________________This posting was submitted with
HTML in it___
____________________________________________________________________________
___
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
