Re: Re: wrapper funcs to cvs cmds

[Bernhard Fischer]

> actually i want to write wrapper on the cvs login
> cmd.
> for this what kind of IPC is needed?

Not quite sure why you would need this, but maybe
"expect" will do your thing.

Bernhard ><>

__

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Möchten Sie mit einem Gruß antworten? http://grusskarten.yahoo.de


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Re: wrapper funcs to cvs cmds

[mehul choube]

Why do you need to login inside your wrapper?

the eg. i gave was for cvs login cmd not my wrapper.
actually i want to write wrapper on the cvs login cmd.
for this what kind of IPC is needed?

mehul.

__
Give your Company an email address like
ravi @ ravi-exports.com.  Sign up for Rediffmail Pro today!
Know more. http://www.rediffmailpro.com/signup/



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: How to make "update -d" ignore a top-level directory?

[Jenn Vesperman]

On Tue, 2002-11-19 at 10:02, Shankar Unni wrote:
 
> How can I achieve what I want: to be able to:
> 
>  * not have to set CVSROOT in the environment.
>  * Be able to issue an "update -d" from the root of my work area, and
>  * not get that junk directory?
> 
> Is there a way? I'm trying to avoid having to do a "radical nms-ectomy"
> (:-/) on my repository..

In CVSROOT in your repository there's a configuration option in one of
the files - I think it's called config - that is 'TopLevelDir'. Set it
to yes, and the directory you're in when you run cvs checkout gets a CVS
subdirectory.

I believe that will do what you want.



Jenn V.
-- 
"Do you ever wonder if there's a whole section of geek culture 
you miss out on by being a geek?" - Dancer.

[EMAIL PROTECTED] http://anthill.echidna.id.au/~jenn/




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Newly added files in a branch

[Larry Jones]

Johnny John writes:
> 
> (a)  I'm working happily in branch A
> (b)  Mainline moving forward in time happily
> (c)  I decide to move my branch forward, i.e. re-sprout it later in time
> (d)  I check out the tip of the mainline
> (e)  I do a cvs update -j of branch A
> (f)  I create a new branch B at the tip and check in results of (e) into 
> the new branch
> 
> Issue I have seen is that any newly added files from branch A do not appear 
> in branch B.  Instead, they appear on the mainline.  So, when I check out 
> the new branch B, I do not get these files.

You went wrong at step (e).  I think this will do what you want:

(e)  Create a new branch B by tagging what you just checked out.
(f)  Move your working directory to the branch with update -r.
(g)  Now merge in Branch A with update -j.
(h)  Checkin should now do the right thing.

-Larry Jones

I wonder what's on TV now. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Newly added files in a branch

[Kaz Kylheku]

On Mon, 18 Nov 2002, Johnny John wrote:

> I'm wondering if CVS treats files newly added in a branch specially.
> 
> Say I have a branch A created some time ago.  My mainline moves along, and 
> at some point later, I want to re-sprout the same branch off the mainline 
> tip.  Typically I do this as follows.
> 
> (a)  I'm working happily in branch A
> (b)  Mainline moving forward in time happily
> (c)  I decide to move my branch forward, i.e. re-sprout it later in time
> (d)  I check out the tip of the mainline
> (e)  I do a cvs update -j of branch A
> (f)  I create a new branch B at the tip and check in results of (e) into 
> the new branch
> 
> Issue I have seen is that any newly added files from branch A do not appear 
> in branch B. 

Yes, this is bogus behavior in CVS; I logged it as an issue. Go to
www.cvshome.org and look up issue 53 ``Cannot add files locally, then
commit later to a different branch''.

As a workaround, what you can do is edit your CVS/Entries by hand. You
will see that the entries for locally added files are not being
properly updated when you update to a branch; these entries do not get
the proper sticky tag.

By the way, how did you do step (f) after (e)? My bug report states
that ``... the tag command prevents the creation of a branch when there
are locally added files''. Are you sure you did (e) and (f) in the
above order?  The problem will appear when you create your sprout
branch first, *then* do the merge, and then switch to the just sprouted
branch to try to commit.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Newly added files in a branch

[Johnny John]

Hello:

I'm wondering if CVS treats files newly added in a branch specially.

Say I have a branch A created some time ago.  My mainline moves along, and 
at some point later, I want to re-sprout the same branch off the mainline 
tip.  Typically I do this as follows.

(a)  I'm working happily in branch A
(b)  Mainline moving forward in time happily
(c)  I decide to move my branch forward, i.e. re-sprout it later in time
(d)  I check out the tip of the mainline
(e)  I do a cvs update -j of branch A
(f)  I create a new branch B at the tip and check in results of (e) into 
the new branch

Issue I have seen is that any newly added files from branch A do not appear 
in branch B.  Instead, they appear on the mainline.  So, when I check out 
the new branch B, I do not get these files.

Anyone has similar issues, and have a better process to deal with this?

thanks,
-Johnny.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: view a file in CVS without it messing with my /CVS/Entries info.

[Eric Siegerman]

On Mon, Nov 18, 2002 at 07:04:11PM -0500, Schoep, Grant @ STORM wrote:
> I want to look at a particular revision of a file, without having it change
> anything in my local directory.

Usage: cvs update [-APdflRp] [-k kopt] [-r rev|-D date] [-j rev]
[...]
-p  Send updates to standard output (avoids stickiness).

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
Just Say No to the "faceless cannonfodder" stereotype.
- http://www.ainurin.net/ (an Orc site)


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: view a file in CVS without it messing with my/CVS/Entries info.

[Kaz Kylheku]

On Mon, 18 Nov 2002, Schoep, Grant @ STORM wrote:

> I want to look at a particular revision of a file, without having it change
> anything in my local directory.

Try the -p option of cvs up.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

view a file in CVS without it messing with my /CVS/Entries info.

[Schoep, Grant @ STORM]

All, hopefully a real simple answer...

I want to look at a particular revision of a file, without having it change
anything in my local directory.

Example... I have test.cxx version 1.15 in my sandbox. 

I'd like to, just go back to see what version 1.11 looked like. stdout or a
file, I don't care. I just want to get a look at that file. Is there any way
to do this with out affecting my current sandbox? Other than maybe placing a
file in there with a different name containing the 1.11 info?
-grant



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: An automatically commit

[Larry Jones]

Giohanna MEndez writes:
> 
> thank you very much for the received help, I am learning branches use, but 
> there is a thing that I do not understand, How can I make a commit to a 
> specific branch?

By checking it out or updating to it before committing.  See:



(You can also specify it explicitly with the -r option to commit, but
that's not recommended -- it's far too confusing to have files in the
same directory on different branches, which is what you'll end up with.)

-Larry Jones

Ever notice how tense grown-ups get when they're recreating? -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

How to make "update -d" ignore a top-level directory?

[Shankar Unni]

In short, this is what I'd like:

* Be able to sit at the root of my work area (where I did the cvs
checkout), and be able to do a simple "cvs update -d".
* Have the "cvs update -d" fetch everything except a single top-level
directory I don't want.

First attempt: I defined the module as

  tms -a src lib doc utl(everything except CVSROOT and
nms)

This works fine, except that the directory where these four end up does
not contain a "CVS" directory, so I cannot sit in that directory and
issue any CVS commands (except by separately setting a CVSROOT
environment variable or using the -d option).

Second attempt: I defined it as

  tms -a . !nms

This works great for *checkout*, and creates a CVS directory with
Entries, etc. The problem is that if I then issue a "cvs update -d" in
that directory, it gets that pesky nms directory (50 MB of useless
stuff).

How can I achieve what I want: to be able to:

 * not have to set CVSROOT in the environment.
 * Be able to issue an "update -d" from the root of my work area, and
 * not get that junk directory?

Is there a way? I'm trying to avoid having to do a "radical nms-ectomy"
(:-/) on my repository..

Thx,

--
Shankar.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: An automatically commit

[david]

> Hi!,
> 
> I want to make an automatically commit inside a logical structure I made on 
> my cvs repository,
> 
> what I am doing at the moment, that is by the way too expensive, it is:
> I make checkout of the version 1, then I modify it, then I made commit, 
> after that and manually I made a checkout of the version 11, then I made the 
> same modification and I made a commit, then I made a checkout of the version 
> 12, then I made the same modification and I made a commit
>
If the files you are proposing to automatically check in are supposed
to be exactly the same, then you don't need to keep separate copies.
You may want to set up a script that will copy the file to where you
want it to go on commit.

If they may not be exactly the same, you don't want to do this 
automatically.  Making the same change to two slightly different
files can result in garbage.

-- 
Now building a CVS reference site at http://www.thornleyware.com
[EMAIL PROTECTED]



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: An automatically commit

[Giohanna MEndez]

Hi,

thank you very much for the received help, I am learning branches use, but 
there is a thing that I do not understand, How can I make a commit to a 
specific branch?

Regards,
  Giohanna

_
MSN Fotos: la forma más fácil de compartir e imprimir fotos. 
http://photos.msn.es/support/worldwide.aspx



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: An automatically commit

[Mike Ayers]

Giohanna MEndez wrote:


  /---Version 11
   /---version 1-/
  /  \
 /\Version 12
version base /---version 2
\---version 3 - Version 31

Each version has:
version base
   |-include (inside some files .h)
   |-server (inside some files .c)
   +-client (inside some files .c)

version 1
   |-include (inside same files as include in version base
 and more files .h)
   |-server (inside same files as server in version base
  and more files .c)
   |-client (inside same files as client in version base
  and more files .c)
   +-communications (inside some files .c)

version 2
   |-include (inside same files as include in version base
  and more files .h -different from version 1)
   |-server (inside same files as server in version base
  and more files .c -different from version 1)
   +-client (inside same files as client in version base
  and more files .c -different from version 1)





I made this logical structure in this way: first I create the version 
base, then from the version base I made a checkout, then I modify it and 
import it with the name version 1, I made the same procedure to create 
version 2 and 3, It is important to say to each modification is 
different between each version, to create the version 11, I made a 
checkout from the version 1, then I modify it and import it with the 
name version 11, I made the same to create version 12. To obtain version 
31: I made a checkout from the version 3, then I modify it and import it 
with the name version 31.

	Didn't this seem more than a bit awkward? (see below)


In this way, I had created modules for each version (at the same level 
in my cvs repository), but what I want to do is: each time I made a 
modification in program of the version 1, and I make a commit, the cvs 
automatically makes a commit for the version 11 and 12. Other example: 
if I made a commit for a modified program of the version base, cvs make 
automatically a commit for the dependent versions from it (according to 
my logical structure). This is my problem: how can I do it automatically?

	By not archiving multiple copies of the same file. (see below)


what I am doing at the moment, that is by the way too expensive, it is:
I make checkout of the version 1, then I modify it, then I made commit, 
after that and manually I made a checkout of the version 11, then I made 
the same modification and I made a commit, then I made a checkout of the 
version 12, then I made the same modification and I made a commit

	This is not only too "expensive", it is too error prone.


Somebody can help me to make this process more automatically?


	I shall try.  First, I must point out your fundamental problem: you 
are trying to solve a configuration problem with an archiving system. 
 This is why your solution is so awkward and error prone.  The thing 
to do is to treat this as a CM problem, and you're halfway home.

	Basically, instead of maintaining so many copies of the same files, 
you should maintain only one copy, and use a manifest and conversion 
script to translate the archive into your chosen directories.  This 
results in far less files to archive.  It also means that your 
"automatic commit" happens by default, although you will need to rerun 
your conversion script each time you commit.  That can be handled with 
a checkin script, if necessary.


	HTH,

/|/|ike




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: An automatically commit

[Larry Jones]

Giohanna MEndez writes:
> 
> Somebody can help me to make this process more automatically?

Read the section of the CVS manual on branching and merging:



It looks like your structure is logically branches, but you're not using
CVS branching support to maintain them.

-Larry Jones

Ever notice how tense grown-ups get when they're recreating? -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: An automatically commit

[Kaz Kylheku]

On Mon, 18 Nov 2002, Giohanna MEndez wrote:

> Hi!,
> 
> I want to make an automatically commit inside a logical structure I made on 
> my cvs repository,

You are trying to implement, in CVS, a completely different version
control model from what the software supports. Versions are not modeled
as new directories in CVS; rather, version history is superimposed
on a directory structure as a separate dimension.

> In this way, I had created modules for each version (at the same level in my 
> cvs repository), but what I want to do is: each time I made a modification 
> in program of the version 1, and I make a commit, the cvs automatically 
> makes a commit for the version 11 and 12. Other example: if I made a commit 
> for a modified program of the version base, cvs make automatically a commit 
> for the dependent versions from it (according to my logical structure). This 
> is my problem: how can I do it automatically?

CVS doesn't know that the modules ``version 1'' and ``version 11'' are
related in any way.  This is a semantic convention of your own which
you have imposed on the repository. If you want to automate your
version control scheme, you have to develop your own software.

If you want to do branching and merging with CVS, you will have
to learn to do it in the manner supported by CVS.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

An automatically commit

[Giohanna MEndez]

Hi!,

I want to make an automatically commit inside a logical structure I made on 
my cvs repository,

I use programs in C, and each version has an structure of directories and 
subdirectories which contain the programs. I have a version base, from it I 
derive version 1, version 2 and version 3, from version 1 I derive version 
11 and version 12, the logical structure is:

  /---Version 11
   /---version 1-/
  /  \
 /\Version 12
version base /---version 2
\---version 3 - Version 31

Each version has:
version base
   |-include (inside some files .h)
   |-server (inside some files .c)
   +-client (inside some files .c)

version 1
   |-include (inside same files as include in version base
 and more files .h)
   |-server (inside same files as server in version base
  and more files .c)
   |-client (inside same files as client in version base
  and more files .c)
   +-communications (inside some files .c)

version 2
   |-include (inside same files as include in version base
  and more files .h -different from version 1)
   |-server (inside same files as server in version base
  and more files .c -different from version 1)
   +-client (inside same files as client in version base
  and more files .c -different from version 1)

version 3
   |-include (inside same files as include in version base
  and more files .h -different from version 1 and version 2)
   |-server (inside same files as server in version base
  and more files .c -different from version 1 and version 2)
   |-client (inside same files as client in version base
  and more files .c -different from version 1 and version 2)
   +-graphics (inside some files .c)

version 31
   |-include (inside same files as include in version 3
  and more files .h)
   |-server (inside same files as server in version 3
  and more files .c)
   |-client (inside same files as client in version 3
  and more files .c)
   +-graphics (inside same files as graphics in version 3
  and more files .c)

I made this logical structure in this way: first I create the version base, 
then from the version base I made a checkout, then I modify it and import it 
with the name version 1, I made the same procedure to create version 2 and 
3, It is important to say to each modification is different between each 
version, to create the version 11, I made a checkout from the version 1, 
then I modify it and import it with the name version 11, I made the same to 
create version 12. To obtain version 31: I made a checkout from the version 
3, then I modify it and import it with the name version 31.

In this way, I had created modules for each version (at the same level in my 
cvs repository), but what I want to do is: each time I made a modification 
in program of the version 1, and I make a commit, the cvs automatically 
makes a commit for the version 11 and 12. Other example: if I made a commit 
for a modified program of the version base, cvs make automatically a commit 
for the dependent versions from it (according to my logical structure). This 
is my problem: how can I do it automatically?

what I am doing at the moment, that is by the way too expensive, it is:
I make checkout of the version 1, then I modify it, then I made commit, 
after that and manually I made a checkout of the version 11, then I made the 
same modification and I made a commit, then I made a checkout of the version 
12, then I made the same modification and I made a commit

In the other example,
I made a checkout from the version base, then I modify it, then I made a 
commit,
I made checkout of the version 1, then I made the same modification in it, 
then I made commit,
I made a checkout of the version 11, then I made the same modification and I 
made a commit,
then I made a checkout of the version 12, then I made the same modification 
and I made a commit,
I made checkout of the version 2, then I made the same modification in it, 
then I made commit,
I made checkout of the version 3, then I made the same modification in it, 
then I made commit,
after that, and finally I made checkout of the version 31, then I made the 
same modification in it, then I made commit,


As I am doing it at the moment, it has its problems because if I forget to 
make some update, I lose the philosophy of my logical structure and the 
other problem is that it takes long time to me and much work to do this,

Somebody can help me to make this process more automatically?

Gracias,
	Giohanna

_
MSN. Más Útil Cada Día http://www.msn.es/intmap/



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: wrapper funcs to cvs cmds

[david]

> Hi,
>  I'm writing a wrappers to an existing command-line based 
> cvs commands
> The program goes like this
> $ cvs login
> (Logging in to [EMAIL PROTECTED])
> CVS password: (enter password here)
> $ messages. eg login sucessful or not.
>
Why do you need to login inside your wrapper?  Once the user has logged
in to a repository (using pserver), CVS writes a file in the
user's home directory and so the user stays logged in.

>  online docs will be of great help.
> 
Most documentation available in printed form is also freely
available on-line.  Start at http://www.cvshome.org.

-- 
Now building a CVS reference site at http://www.thornleyware.com
[EMAIL PROTECTED]



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

wrapper funcs to cvs cmds

[mehul choube]

Hi,
I'm writing a wrappers to an existing command-line based 
cvs commands
The program goes like this
$ cvs login
(Logging in to [EMAIL PROTECTED])
CVS password: (enter password here)
$ messages. eg login sucessful or not.

Basically my program needs to issue the cvs login 
command, wait for the
password prompt, sends the password and wait for the login 
messages. My
question is what kind of IPC should I use?

online docs will be of great help.

mehul.
__
Give your Company an email address like
ravi @ ravi-exports.com.  Sign up for Rediffmail Pro today!
Know more. http://www.rediffmailpro.com/signup/



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

wrapper functions on cvs cmds

[mehul choube]

__
Give your Company an email address like
ravi @ ravi-exports.com.  Sign up for Rediffmail Pro today!
Know more. http://www.rediffmailpro.com/signup/

Hi,
I'm writing a wrappers to an existing command-line based cvs commands
The program goes like this
$ cvs login
(Logging in to [EMAIL PROTECTED])
CVS password: (enter password here)
$ messages. eg login sucessful or not.

Basically my program needs to issue the cvs login command, wait for the
password prompt, sends the password and wait for the login messages. My 
question is what kind of IPC should I use?

online docs will be of great help.

mehul.

RE: WinCVS problem - "sandbox" files not shown

[Stefan Andersson]

Ok!! Now i've got it =) 
I should probably have done my homework before I posted the question... 

The problem was that I've had incorrect filter settings for a long
time, but since we have the "DST-bug" which makes all files marked as 
changed the files were shown earlier, but when the time was changed again
CVS began to behave correctly - which caused our problems!

Thanks a lot!!

--Stefan

Fresco's Discovery:
If you knew what you were doing you'd probably be bored.



-Original Message-
From:   Mike Ayers [mailto:[EMAIL PROTECTED]]
Sent:   Sun 11/17/2002 6:42 AM
To: Stefan Andersson
Cc: [EMAIL PROTECTED]
Subject:Re: WinCVS problem - "sandbox" files not shown
Stefan Andersson wrote:

> (I've tried all combinations of the "Show" buttons, but the only 
> thing that differs is if non-cvs files is shown or not...)

Incorrect.  There are a number of "Show" buttons colored red.  Those 
buttons will hide all files *except* those shown.  Please check those 
and make sure none are depressed.  If any are, tell them a good joke, 
or just click them, and your hidden files should come out to play.


/|/|ike







___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: first change on a branch causes no change to show up in -rTAGA::TAGB

[Matthew Herrmann]

Hi All,

I have taken Larry's suggestion and installed the latest dev version and it
is better, but still not 100%.

Here is the problem I found on development version of CVS:

For a file, FILE1:

Tags:

=
TAG2: 1.3.2.1
TAG1: 1.3
TAG2_BRANCH: 1.3.2.1.0.2

Revisions:

=
revision 1.3
date: 2001/12/16 23:13:12;  author: matthew;  state: Exp;  lines: +1 -1
branches:  1.3.2;
...

-
revision 1.3.2.1
date: 2002/10/17 23:36:14;  author: matthew;  state: Exp;  lines: +1 -1
...

=

the revision 1.3.2.1.0.2 doesn't exist, i'm guessing because it is a magic
branch tag. anyway, that seemed a little weird to me because all my other
tags, even
branch tags are always on a physical tag (or so I thought).

doing:

cvs log -rTAG1::TAG2 should produce log info for 1.3.2.1, but it produces
info
for 1.3 instead.

The interesting thing is that 1.3.2.1 is the start of another
branch which was a branch off our production branch for a minor bug-fix. So
I think this is the case that is not handled.

I have got some other extraneous changes but I think they are very likely
due to
this same problem.

cheers,
matt

Matthew Herrmann wrote:
>
> Hi All,
>
> I'm using cvs2cl to generate version differences on branches, but I'm
having
> trouble with picking up changes where no change was previously there. I
> think the problem is one in cvs log, though, not cvs2cl.
>
> Here's the command I use
>
> cvs2cl -w -f ChangeLog_%1_To_%2.txt -r%1::%2
>
> the scenario that breaks it is:
>
> working on branch BRANCH1
>
> at TAG1, on BRANCH1 : file is on 1.23
> at TAG2, on BRANCH1 file is on 1.23.1.4 after changes
>
> the problem is that even when looking at 2 tags on the same branch, it is
> only after the first change to the file that it becomes _really_ on the
> branch, before that, the tag is still officially on the trunk.
>
> What would fix this for me is for 1.23 => 1.23.x.y to be considered on the
> same line. At the moment the line is only being start just after 1.23
which
> means I'm losing a significant number of changes out of these history
logs.
>
> are there any patches available for this problem? some others must have
had
> this problem with log -r.
>
> cheers,
> matt
I assume you are speaking of either
http://search.cpan.org/author/FLUFFY/CVSUtils-1.00/
or http://www.red-bean.com/cvs2cl/

the '-r' option to cvs2cl is for:
[-r, --revisions  Show revision numbers in output]

what I think you want is to pass options to cvs log so you should use -l
"options":
[-l OPTS, --log-opts OPTS Invoke like this "cvs ... log OPTS"]

if you want to pass revisions to cvs log I believe it should be something
like

cvs2cl -l "-r%1::%2" -w -f ChangeLog_%1_To_%2.txt

I use the global compress option as
cvs2cl.pl -g "-z9" -r -t -f cl.txt
so I think the line I gave you above will work, if cvs log will accept
whatever
"-r%1::%2" evaluates to.

--
I'd crawl over an acre of 'Visual This++' and 'Integrated Development
That' to get to gcc, Emacs, and gdb.  Thank you.
-- Vance Petree, Virginia Power



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs