On Thu, Apr 04, 2002 at 03:45:51PM +1000, Sonam Chauhan wrote:
> PROBLEM #1: CVS usage must be transparent. This means no 'CVS' meta-directories
> are allowed in the development(working-set) file hierarchy since the proprietary
> development environment modifies this hierarchy directly. How can I do this?
>
> The proprietary IDE (something called 'webMethods B2B'), though lacking version
> control, has a inbuilt release mechanism. It zips up release directories in the
> working set. These ZIP files are then distributed to other servers. Hence we end
> up with CVS directories in 'live' servers. This takes us far far away from
> 'support land' and also may cause complications with the software's internal
> functioning.
1. Have you looked for a way to tell webMethods to ignore certain
files or directories? I imagine so, but I gotta ask...
2. Are there any other points where webMethods lets you customize
the deployment process? Wherever a hook exists, there's the
possibility of using it, with a little lateral thinking, to
get rid of the offending CVS directories without disturbing
the sandbox itself.
3. How often do you need to release? One possibility would be:
- work in a sandbox with CVS directories -- edit, compile (if
what you're working on needs that), test, commit, repeat
- to cut a new release:
- "cvs export" your work to a temporary directory
- tell webMethods to deploy the latter
But if you make several releases a day, even that'd be pretty
cumbersome.
Finally, let me add a "me too": trying to build shadow sandboxes
using links seems very fragile and error-prone. Give up on CVS
before going there.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. [EMAIL PROTECTED]
| | /
"Outlook not so good." That magic 8-ball knows everything!
I'll ask about Exchange Server next.
- Anonymous
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
