Return-Path: Mailing-List: contact dev-help@ant.apache.org; run by ezmlm Delivered-To: mailing list dev@ant.apache.org Received: (qmail 90851 invoked from network); 12 Mar 2003 17:47:35 -0000 Received: from mailhost2.cnf.com (HELO ljcqs053.cnf.com) (63.230.177.24) by daedalus.apache.org with SMTP; 12 Mar 2003 17:47:35 -0000 Received: from cnfqs057.cnf.prod.cnf.com (localhost [127.0.0.1]) by ljcqs053.cnf.com (Postfix) with ESMTP id 3052C6C1 for ; Wed, 12 Mar 2003 09:47:36 -0800 (PST) Received: by cnfqs057.cnf.prod.cnf.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Mar 2003 09:47:35 -0800 Message-ID: <7B73D5F649D0D311B1E30008C7A4D92A1C2E8381@cnfqs029.cnf.prod.cnf.com> From: "Anderson, Rob H - VSCM" To: 'Ant Developers List' Subject: RE: enhanced pvcs task for PVCS version 7.5 Date: Wed, 12 Mar 2003 09:47:13 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Apparently there is some confusion around repository and config file. I apologize for not being very clear about this. Let me explain. By default, when you create a Version Manager project database a config file is created in the archives directory. You can see the config file name and location through the GUI if you right click the project database and choose "Properties". You can, however, specify a config file to use when you create the project database (in the advanced tab) or at any time through the "Properties" dialog. For example: I have a local repository that I created using the defualts ("Create a new config file" in the Advanced tab) for a config file. The layout is as follows; Project Database (-pr) c:\pvcs Config file c:\pvcs\archives\cos0nbu1.cfg I have a shared project database that was created with a custom config file ("Use an existing configuration file" in the Advanced tab) Project Database (-pr) s:\Projects\NOONAN Config File s:\configuration files\NOONAN.cfg In both cases, using get works fine without the -c option unless I am doing a get by promotion group. When doing a get by promotion group I will get an error that says "get: Group "CM" does not exist in promotion hierarchy.", because the promotion model is defined in the config file. So, if I specify the config file with the -c option, this error goes away and the get by promotion group works as expected. So using the pvcs task is no different. Doing a normal "get" works fine, but a "get by promotion group" fails with the error mentioned above. If there was a configfile attribute to the pvcs task I could use it to get by promotion group. Currently I can only use it to do a "get the default revision". Does this make sense? -Rob A -----Original Message----- From: cp533@daimlerchrysler.com [mailto:cp533@daimlerchrysler.com] Sent: Tuesday, March 11, 2003 3:22 PM To: Ant Developers List Subject: RE: enhanced pvcs task for PVCS version 7.5 PVCS task works with version 7.5 as is, unless you are pointing to a config file other than the default. "repository" attribute is used to point to config location, do you mean some other configuration files; and as you know this a required attribute, so no defaults. The advantage to using "pcli get" rather than "get" is that pcli is smart about config files, which has been a problem for me with the existing PVCS task.I'm a little new to PVCS Version Manager, so if there are other advantages please let me know. Of course pcli is pretty slow compared to the old school "get". Following are advantages stated by our support team:- All project teams that have been using the legacy Commands (i.e. get, put) will need to convert to 'PCLI'. Using the PCLI commands is just like using the I-NET client or Windows client. These three interfaces update serialized database files that the PVCS Version Manager software uses. These serialized database files contain all the information for the archives. So if one member is using PVCS I-NET and modifies an item that modification will appear for another team member that is using the PCLI commands. Using the old sget or sput does not update these serialized files. 1.) Easier/More User Friendly 2.) More Reliable 3.) Provides your team the choice to use Command Line or I-NET Client. 4.)May run a little slower since it is updating the serialized files. It would be nice if the existing PVCS task had a "configfile" parameter. Can you explain a bit more about this? because I don't seem to have any problem when using with old get, with respect to the config files. Please find the attachment. Don't miss the added (two) properties. ..(See attached file: Pvcs.java) Chandra Periyaswamy "Anderson, Rob H - VSCM" To: "'Ant Developers List'" Subject: RE: enhanced pvcs task for PVCS version 7.5 03/11/2003 05:00 PM Please respond to "Ant Developers List" PVCS task works with version 7.5 as is, unless you are pointing to a config file other than the default. The advatantage to using "pcli get" rather than "get" is that pcli is smart about config files, which has been a problem for me with the existing PVCS task. I'm a little new to PVCS Version Manager, so if there are other advantages please let me know. Of course pcli is pretty slow compared to the old school "get". It would be nice if the existing PVCS task had a "configfile" parameter. I would like to check out your source code. Please attach it to an email and send it to the list. Thanks, -Rob A -----Original Message----- From: cp533@daimlerchrysler.com [mailto:cp533@daimlerchrysler.com] Sent: Tuesday, March 11, 2003 12:14 PM To: dev@ant.apache.org Subject: enhanced pvcs task for PVCS version 7.5 Hi, I'm a greenhorn to this list, so please pardon my mistakes if any. I modified the pvcs task to work with PVCS VM version 7.5. Instead of a old "get", I use "pcli get" in this modified version. It has been tested and used in my project. I have tested on sun OS. I would be glad to submit the source, if you'd like. Please let me know what you think. I also think keeping the support for the old "get" may also seem important for the community. :o) Chandra Periyaswamy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional commands, e-mail: dev-help@ant.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional commands, e-mail: dev-help@ant.apache.org