Can I check out a new directory without getting the files in it?

[b_dompe]

I'm trying to find a way to check out a new directory without 
checking out the files within that directory.  I currently 
execute "cvs co - l ", which gets the directory, 
but also any files that exist in it.  There's -d, but that only gets 
empty directories.  Is there a way to check out only the directory 
even if it contains files?

Alternatively, checking out the directory with just one specific file 
in it could be adapted to what we need.  But we can't have it 
retrieve every file.

Thanks.


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

CVS History logging

[Gaelen Gallashant]

I need to know what files and the commands to specify in the files for
logging the history of changes in source files. I suspect this is need
for CFR auditing. The URL below should have this information.
 
Specifically, when a file is committed to CVS I need the commit
comment from the user placed into the source file. My hope is that the
comment will be placed on the alter blocks as seen by a CVS diff. The
only files that should be impacted by this are *.h and *.cpp files.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: merge mode for XML

[Lee Sau Dan]

> "Noel" == Noel Yap <[EMAIL PROTECTED]> writes:

>> If CVS had away to use modular plug in "diff" and "merge"
>> programs, we could setup a wrapper file that would
>> automatically diff/merge the file differently based on the
>> extension.  e.g.:
>> 
>> *.xml xml_dm *.html html_dm

Noel> Ideally, the diff/merge tool would be tied to the type of

Please add also a keyword-substitution tool to the check list.


Noel> the file and the type of the file is initially set depending
Noel> on the extension.

No.  Not on extension, but based on *regular expressions*, or at least
shell-style   pattern  matching   expressions.   Extensions   are  too
simplistic.  (c.f. CVSROOT/cvswrappers,  CVSROOT/cvsignore) 


Noel>   This way, one would be able to change the
Noel> type of the file independent of its extension.

Yes.   Some mechanisms  like  ~/.mime.types plus  ~/.mailcap would  be
desirable.  But  one more complication  would be the version  of these
external programs.  Maybe, CVS needs to keep track of which version of
the tools  were used for which  file revisions, so as  to reliably and
faithfully reproduce any snapshot.


-- 
Lee Sau Dan §õ¦u´°(Big5)~{@nJX6X~}(HZ) 

E-mail: [EMAIL PROTECTED]
Home page: http://www.informatik.uni-freiburg.de/~danlee
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Sharing the same physical file in multiple directories

[Karsten, Paul]

I have one config file that must exist in several directories in my project.
I would like to be able to have CVS create this file in all its locations
and still only have it stored once in the repository.  Any idea how or if I
can do that.

Thanks

Paul Karsten


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

How to retain revision history when copying files from one cvs project to another?

[Neetha Vuppala]

Hi,
We have all our source code in the CVS repository as
one project. Now we want to start a new project in
CVS. But we will be requiring files from the existing
project into the new project. How can we copy/move the
files over to the new project without losing their
revision history? Is there a way to do this?
Does the cvs import command work for doing this?
Please let me know if anyone has an answer.

Thanks,
Vuppala.




__
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

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

Re: merge mode for XML

["Jesús M. NAVARRO"]

Hi, Greg:

Greg A. Woods wrote:
> [ On Wednesday, May 1, 2002 at 11:34:02 (-0400), Gary Bisaga wrote: ]
> 
>>Subject: RE: merge mode for XML
>>
>>Good point, Noel. At my last job we had a partner we were required to
>>connect to, and it was a job getting even an example XML document out of
>>them, let alone a DTD or schema.
> 
> 
> You guys are just re-iterating all the silly arguments that have come
> and gone with EDI.  New face, same old problem.
> 

Yeah! been there seen that.  What's the good of XML if there's no 
concert about the DTD/schema to be used!?
-- 
SALUD,
Jesus
***
[EMAIL PROTECTED]
***
Desde Zaragoza, busco empleo - 
http://www.geocities.com/jesusm_navarro/CV/cv.html
***

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

Unable to add new files after checking out a tag

[b_dompe]

We bring a new tree up to date with the latest 'stamped' release by 
using "cvs update -r", where the release was created 
with "cvs tag -RF ".

This seems to work for existing files.  However, when people try to 
add a new file to the repository, they get the error "cannot add file 
on non-branch tag ".  

We've only ben able to fix it by erasing the tree and doing a cvs co. 
That gets the latest revision of every file though, which is not what 
we want. Is there a way to fix this?


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

Re: CVS File Time stamp preserve ...

[Ingolf Steinbach]

* Seema Agarwal <[EMAIL PROTECTED]> [2002-05-02 09:00]:
> I'd like 
> to preserve the time stamp of the "incoming files" when putting them into 
> my repository. Is thereany way of doing this ?

"import" is your friend. Use it along with the -d option.

Ingolf

PS: CC'ed to info-cvs as it is more appropriate there.
-- 

Ingolf Steinbach   Jena-Optronik GmbH
[EMAIL PROTECTED]   ++49 3641 200-147
PGP: 0x7B3B5661  213C 828E 0C92 16B5  05D0 4D5B A324 EC04

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

Re: Group permissions to branches

[Brian Poynor]

I'm not saying that you should not use a separate lock directory, just
that it won't help you solve this problem.

You cannot control access to branches using unix permissions, since
the same RCS files contains all the branches. Users need write
permission to the directories to commit to any branch.

-Brian

On Mon, Apr 29, 2002 at 07:17:26PM +0500, Muhammad Shakeel wrote:
> Dear Brian,
> Hi
> 
> Sorry i am asking a question regarding a little old thread on mailing list. Can u 
>please explain why u r not recomending to use a option of using an alternate 
>directory for lock files, specially in this case. 
> 
> Regards,
> shakeel
> 
> 
> Brian Poynor wrote:
> 
> >You can't really do this with the CVSROOT/passwd file. But if you are
> >primarily concerned about who can commit to Branch A and Branch B (as
> >opposed to checkout), you can implement that using CVSROOT/commitinfo.
> >
> >(I answered a similar request earlier, and discounted the option of
> >using an alternate directory for lock files. This is one of the
> >primary reasons why. You cannot use unix permissions to govern which
> >branch a user can work on, which is a fundamental need in my
> >experience. I believe this is the only mechanism in CVS for this.)
> >
> >Your commitinfo script can examing the CVS/Tag file. It's the trunk
> >(mainline) if it doesn't exist, or doesn't have "T" as the first
> >character in it, otherwise the branch name follows the "T". It is more
> >work, but also more technically correct to examine the tag value in
> >the CVS/Entries or CVS/Entries.Log file for each file being committed
> >instead, since it is possible for a user to update a file from a
> >different branch into her tree and commit it. The CVS/Tag doesn't
> >necessarily reflect the branch of every file in the directory.
> >
> >An additional thing I check that all the files being committed are in
> >the same branch, since committing to two different branches at once is
> >almost always a result of user error, and it can be painful to
> >correct. I figure they can commit twice if that is their intent.
> >
> >Once you know the branch of the file, you can check that the user is
> >allowed to commit to that branch using a database of your own design 
> >(could be as simple as a text file with usernames for each branch).
> >
> >Just make sure that when your commitinfo scripts disallow a commit,
> >they print a very clear error message to STDOUT. This will save you
> >and your cvs users a lot of guesswork later.
> >
> >-Brian
> >
> >On Tue, Apr 09, 2002 at 12:33:07PM -0400, Danial Islam wrote:
> >
> >>I'm not sure if I posted this already, but here goes again:
> >>
> >>In my repository I have set up a main trunk with two branches coming out
> >>of it, e.g.  Branch A and
> >>Branch B.Is it possible to restrict Branch A to a certain group of
> >>users, and  Branch B to another group of users?  How would this be done
> >>in UNIX?
> >>
> >>How would I modify the CVSROOT/passwd file to accomodate this? Right now
> >>my passwd file currently has [unix ID]:[encoded password] for each user.
> >>
> >>Any help would really, really be appreciated!
> >>
> >>
> >>Danial.
> >>
> >>
> >>___
> >>Info-cvs mailing list
> >>[EMAIL PROTECTED]
> >>http://mail.gnu.org/mailman/listinfo/info-cvs
> >>
> >
> >___
> >Info-cvs mailing list
> >[EMAIL PROTECTED]
> >http://mail.gnu.org/mailman/listinfo/info-cvs
> >
> 
> --
> 
> 

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

Re: merge mode for XML

[Lee Sau Dan]

> "Paul" == Paul Sander <[EMAIL PROTECTED]> writes:

Paul> A better implementation would be to code a symbolic name for
Paul> the merge tool in a newphrase in the admin section the RCS
Paul> file, and look up that symbolic name on the client to locate
Paul> the proper tool.

Good idea!  There  could be a look up table in  CVSROOT to provide the
defaults,  and  then the  client  will have  its  own  config file  to
override the defaults.  (Like CVSROOT/cvsignore vs. ~/.cvsignore.)




-- 
Lee Sau Dan §õ¦u´°(Big5)~{@nJX6X~}(HZ) 

E-mail: [EMAIL PROTECTED]
Home page: http://www.informatik.uni-freiburg.de/~danlee
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

cvs remove: removing files not locally?

[Stefan Bertels]

Hi!

How can I remove a file in the repository without deleting it locally?

Case: I check in a file by accident and want it removed from the
repository. But I need the file. Think of it as per-user options regarding
to a project.

When I call remove the local file will be removed at my machine now and at
all other users machines at the next update.

I know that this will probably not be easy to solve - my thoughts:

a) _every_ user has to backup the file for himself,
   one user removes it from the repository,
   all users restore the file (now a noncvs file)

b) I remove the file from the repository (e.g. directly),
   _every_ user has to modify his CVS/Entries (remove the line)

Both variants are critical because if they don't update the file or they
don't remove it from CVS/Entries before updating the next time, cvs will
delete the file.

Any ideas?

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

read-only access on module basis in one repository

[Andreas Thalau]

Hi folks,

as I read on http://www.cvshome.org/docs/manual/cvs_2.html#SEC36 it is
possible to gain read-only access to the repository for some users.
I can´t find a hint on managing this for one repository based on
modules.

This is what I like to have:
- user "A" read-write access to module "M-A" + "M-B"
- user "B" read-only access to module "M-A" + read-write access to
module "M-B"
(Module "M-A" and module "M-B" are in the same repository)

As I understand the docs mentioned above readers/writers files only
affect the whole repository. They are not module dependend. Maybe I´m
wrong, or there is another way to manage such situation.

Any hints are welcome. Thanks.


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

FW: Extracting All Versions of a File From CVS

[Laura Hopkins]

I'm trying to extract _all_ versions of a CVS file into a directory.  Any
ideas how to do this or whether it can be done?  

Many thanks.

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

RE: merge mode for XML

[Glew, Andy]

[Greg Woods]:
>... conversations about XML and DTDs ...
> ...
> "well formed" by definition should mean in conformance to a 
> pre-existing DTD!
> ...
> Do you build relational databases without defining a schema?  

Well, I wrote Perl-SQL, a relational database system that
is self-schematizing - where every record can define its own schema,
with its own fields.

Motivation: schema changes in most existing relational databases are
onerous.
Even just adding fields is painful. Self-schematization allows new fields to
be
added on the fly, improving documentation of the experiment results 
that are my target data, because any observed features can be easily added
to the schema in a structured way.  As opposed to all of those database
schemas
that have a miscellaneous text or comment field, where far too often all the
critical data that you wish to process lives. Self-schematization allows you
to
do all SQL operations across spontaneously added fields.

---

3-4 years ago I discussed self-schematization with Prof. David Dewitt, a man
of some
reknown in database circles.  His take is that self-schematization was not 
done in the early days to save space, and that now it is not unreasonable to
do so.

However, rather than Perl-SQL, he pointed to me towards XML, saying
something
like "well formed SQL doesn't require a schema or DTD -- that is the
future."

---

I.e., Greg, not all RDBMS experts agree with you about schemas; ditto DTDs.

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

Moving a module from one repository to another

[Andreas Patock]

Hello NG,
is there a chance to move a module from one repository to another? I want to
create different repositories for each development environment, and so I
must splitt my old repository. Of course I could simply checkout a modul and
import it to the new repository - but all my old revisions and tags get lost
this way.

Thanks for any help

BTW is there a faq for this group?


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

Re: merge mode for XML

[Lee Sau Dan]

> "Sean" == Sean Hager <[EMAIL PROTECTED]> writes:

Sean> I agree that XML is overkill, but the truth is that it is
Sean> here to stay.

Sean> XML is fastly becoming excepted as the defacto standard for
.

"accepted"?  :)


Sean> If CVS had away to use modular plug in "diff" and "merge"
Sean> programs, we could setup a wrapper file that would
Sean> automatically diff/merge the file differently based on the
Sean> extension.

Yeah.  That'd  be a cool feature.  But  then, CVS will no  longer be a
standalone  program.  If  you move  the repository  to  another server
where the modules are missing, how would you expect CVS to behave?

Consider the  case where programmers are working  on UNIX workstations
with  an NFS  mounted CVS  repository.   The "cvs"  command just  runs
locally,  without using  the  CVS client-server  operations.  In  this
case, it is possible that  those pluggable modules are present on some
workstations but not the others.   So, files commited from one machine
may fail to  check out in another.   And how can we now  make sure the
snapshots  (tags) is  really  reproducible, when  CVS  now depends  on
extension modules?

Some more thoughts  have to be made before  it becomes reliable.  Some
more changes to the current  architecture will be needed.  This is not
a  simple  change.  Of  course,  I'm  not  saying pluggable  extension
modules  is  a  bad  thing.   And  it  would  be  also  nice  to  have
keyword-substitution modules, too, so that we can keep $Id$ as comment
tags in  GIF/JPEG/PNG/TIFF, for instance.  But some  major redesign of
CVS would  be required to manage  the which versions  of which modules
were used  to commit which changes,  so that CVS  could faithfully and
reliably reproduce the snapshots.




-- 
Lee Sau Dan §õ¦u´°(Big5)~{@nJX6X~}(HZ) 

E-mail: [EMAIL PROTECTED]
Home page: http://www.informatik.uni-freiburg.de/~danlee
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: splitting CVSROOT/modules into multiple files?

[Andreas Thalau]

On Fri, 26 Apr 2002 15:21:44 -0400, "Frederic Brehm"
<[EMAIL PROTECTED]> wrote:

>At 0:42 +0200 4/26/02, Andreas Thalau wrote:
>>
>>We have a dozen (the number is continuously growing) projects with five
>>up to ten sub-modules for each project in one repository and the modules
>>file is getting more and more "unreadable". This is why we like to have
>>it separated into one file per project. Maybe there are many more
>>advantages when making this possible which we can´t figure out
>>yet...(we´re new to cvs..)
>
>#
>
>
>You can put lots of whitespace and lots of comment lines in a modules
>file. Can't you increase the readability that way?
>
>
>#

Hi Fred,

o.k. I think for now this is the easiest way to solve the problem of
readability. Thanks for the hint.

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

CVS diagraming tools

[Max]

I'm hoping to untangle a CVS hairball and need a good charting tool
that will allow me to run against a repository and generate a diagram.
 Is there anything out there that already does this?

Thanks.

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

Re: File Locking with CVS

[Matthew Persico]

Greg A. Woods" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [ On Monday, April 29, 2002 at 15:48:37 (-0500), Gilroy, Michael -AES
wrote: ]
> > Subject: File Locking with CVS
> >
> > My manager won't let me use CVS with concurrent versions of files.  I
need
> > to have the file locked when I edit the file (cvs edit) so that no one
else
> > can do a 'cvs edit' until I either do a 'cvs unedit' or a 'cvs commit'.
> > This would be similar to the way SCCS and RCS work.
>
> Yes, it is.  Perhaps you should be using SCCS or RCS instead of trying
> to use the Concurrent Versions System.
>
I disagree. Take it one step at a time. Import the files. Do a cvs admin -L
on all of them. Make sure everyone does cvs checkout -l. Once they get
comfortable with sandboxes, start cvs admin -U some of the files, especially
those you work on. That is what I am doing. I have set up locking for those
who want it. I don't. I talk it up all the time. They'll come around.

> >  However, I also need
> > some of the advanced features that only CVS can provide.
>
> There are litterally dozens of front-ends available for RCS (and some
> for SCCS) that may provide all or most of the "advanced" features you
> claim you need.  Perhaps you should investigate using one of those other
> front-ends with RCS (or SCCS).
>
> --
> Greg A. Woods
>
> +1 416 218-0098;  <[EMAIL PROTECTED]>;  <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird
<[EMAIL PROTECTED]>
>


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

Any plan to merge cvspwd into cvs?

[Ben Kial]

I have been using "cvspwd" to manage my CVS user accounts in
my :pserver host so that I don't have to create Unix accounts for
each CVS user. However, "cvspwd" can only be executed by the
repository owner, which means each CVS user cannot change
their own password...

Is there any plan from the CVS team to include "cvspwd" into future
releases of CVS and have a "cvs passwd" command for users to
manage their own passwords?


Ben


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

helmut schmidt/CH/SMAG ist außer Haus.

[schmidt . helmut]

Ich werde ab  02.05.2002 nicht im Büro sein. Ich kehre zurück am
06.05.2002.

Ich werde Ihre Nachricht nach meiner Rückkehr beantworten.


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

Re: Moving CVS repository

[Greg A. Woods]

[ On Thursday, May 2, 2002 at 18:01:03 (-0400), Larry Jones wrote: ]
> Subject: Re: Moving CVS repository
>
> Greg A. Woods writes:
> > 
> > It's irrelevant how they get that way.  If all the files in given
> > working directory hierarchy are not from the same repository then the
> > user loses.
> 
> In what sense?  CVS has handled that just fine for quite some time now.

only in its most basic form

there are zillions of basically unsolvable issues which arise if there's
any use of *info files.

I seem to remember a discussion on this issue back in the dark ages
about this issue and the resolution would be that such "accidents" would
be officially unsupported.

-- 
Greg A. Woods

+1 416 218-0098;  <[EMAIL PROTECTED]>;  <[EMAIL PROTECTED]>;  <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]>

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

Re: Removing a branch

[Eric Siegerman]

On Thu, May 02, 2002 at 05:59:21PM -0400, Danial Islam wrote:
> What is the safest/best way to remove a branch full of files from the
> repository?
> 
> I was thinking that  cvs rtag -d  or cvs tag -d 
> are not sufficient enough.

You're right.  Those will only remove the branch tags; all the
revisions will still be there -- but unlabelled now, so nobody
will know what they signify.

You'll have to go through and "cvs admin -o" all the revisions on
the branch.  But be careful!  You could easily trash trunk
revisions by mistake.  And once trashed, they're trashed for
good; "cvs admin -o" CANNOT be undone.

It's probably better -- certainly safer -- to just leave the
branch alone, and tell everyone to ignore it...

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
Anyone who swims with the current will reach the big music steamship;
whoever swims against the current will perhaps reach the source.
- Paul Schneider-Esleben

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

Re: Moving CVS repository

[Larry Jones]

Greg A. Woods writes:
> 
> It's irrelevant how they get that way.  If all the files in given
> working directory hierarchy are not from the same repository then the
> user loses.

In what sense?  CVS has handled that just fine for quite some time now.

-Larry Jones

There's a connection here, I just know it. -- Calvin

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

Removing a branch

[Danial Islam]

What is the safest/best way to remove a branch full of files from the
repository?

I was thinking that  cvs rtag -d  or cvs tag -d 
are not sufficient enough.


Danial.



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

Re: Moving CVS repository

[Greg A. Woods]

[ On Thursday, May 2, 2002 at 15:38:27 (-0500), Joi Ellis wrote: ]
> Subject: Re: Moving CVS repository
>
> On Thu, 2 May 2002, Greg A. Woods wrote:
> > 
> > If I'm not mistaken the CVS/Root file _MUST_ be identical throughout an
> > entire module's working directory, regardless of whether module aliases
> > are used or not.  A given working directory _MUST_ always come from the
> > same repository.
> > 
> > (Of course idiot users could maybe manually check out one module from
> > another repository into the same working directory, but they lose and
> > that's just too bad for them, IMNSHO!  :-)
> 
> Yes, that is true. 
> 
> However, this isn't what I said.  I said users often nest modules.

It's irrelevant how they get that way.  If all the files in given
working directory hierarchy are not from the same repository then the
user loses.  It matters not whether they were checked out with a module
alias (which automatically "nests modules"), or by hand, or whatever.

What you've described doesn't seem to indicate any deviation from this
rule.

-- 
Greg A. Woods

+1 416 218-0098;  <[EMAIL PROTECTED]>;  <[EMAIL PROTECTED]>;  <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]>

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

Re: Moving CVS repository

[Joi Ellis]

On Thu, 2 May 2002, Greg A. Woods wrote:

> [ On Thursday, May 2, 2002 at 13:39:06 (-0400), Eric Siegerman wrote: ]
> > Subject: Re: Moving CVS repository
> >
> > On Wed, May 01, 2002 at 01:42:44PM -0500, Joi Ellis wrote:
> > >   find . -type f -name 'Root' | \
> > >  xargs perl -pi.bak -e 's/localhost/some.hostname/'
> > > [...]
> > > I prefer using perl rather than a 'cp' because some of our modules
> > > are nested and I don't trust the Root file to be identical all
> > > through the tree.  Maybe they are, maybe they aren't.
> > 
> > Agreed.
> 
> If I'm not mistaken the CVS/Root file _MUST_ be identical throughout an
> entire module's working directory, regardless of whether module aliases
> are used or not.  A given working directory _MUST_ always come from the
> same repository.
> 
> (Of course idiot users could maybe manually check out one module from
> another repository into the same working directory, but they lose and
> that's just too bad for them, IMNSHO!  :-)

Yes, that is true. 

However, this isn't what I said.  I said users often nest modules.  This is
particularly common in Java applications.  There is at least one IDE that
leads its users into building such bastard workspaces.  I see this come
up a lot on the JBuilder newsgroups because JBuilder doesn't support
nested modules well (if at all) but users are trying to coerce JBuilder
into adjusting itself to an existing nested workspace.

Module A:
  dirA1
  dirA2

Module B:
  dirB1
  dirB2

Workspace:
  dirA1
  dirA2
 dir B1
 dir B2

In this sort of nested workspace, one can't simply cp a Root file from
the top of the workspace into all of the subdirectories because B's
Root is different.

  

-- 
Joi EllisSoftware Engineer
Aravox Technologies  [EMAIL PROTECTED], [EMAIL PROTECTED]

No matter what we think of Linux versus FreeBSD, etc., the one thing I
really like about Linux is that it has Microsoft worried.  Anything
that kicks a monopoly in the pants has got to be good for something.
   - Chris Johnson


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

Re: Moving CVS repository

[Greg A. Woods]

[ On Thursday, May 2, 2002 at 13:39:06 (-0400), Eric Siegerman wrote: ]
> Subject: Re: Moving CVS repository
>
> On Wed, May 01, 2002 at 01:42:44PM -0500, Joi Ellis wrote:
> >   find . -type f -name 'Root' | \
> >  xargs perl -pi.bak -e 's/localhost/some.hostname/'
> > [...]
> > I prefer using perl rather than a 'cp' because some of our modules
> > are nested and I don't trust the Root file to be identical all
> > through the tree.  Maybe they are, maybe they aren't.
> 
> Agreed.

If I'm not mistaken the CVS/Root file _MUST_ be identical throughout an
entire module's working directory, regardless of whether module aliases
are used or not.  A given working directory _MUST_ always come from the
same repository.

(Of course idiot users could maybe manually check out one module from
another repository into the same working directory, but they lose and
that's just too bad for them, IMNSHO!  :-)

-- 
Greg A. Woods

+1 416 218-0098;  <[EMAIL PROTECTED]>;  <[EMAIL PROTECTED]>;  <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]>

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

Upgrading to 1.11 from 1.10

[Danial Islam]

In UNIX,  if I had the repository and all the scripts set up in CVS
1.10,  then if i start using the binary for CVS 1.11 during the middle
of our code development, will my repository get screwed up?


Danial


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

Re: [OT] Example for Perlwrapper around cvs login?

[Joi Ellis]

On Thu, 2 May 2002, Oliver Fischer wrote:

> Sorry, may be a little bit offtopic...
> 
> Does someone have example perl script to wrap cvs login via open2/3
> and IO::Select? I am not able to get my one working.
> 
> Thanks...
> 

Yes.  Here's one I use in a SOAP-based distributed build system.
I've expressed the routine and the stuff it calls as shell 'here' documents
just because I'm feeling geeky today.  My code is OO and passes in a target
object whose fields contain the info needed to access the repository.
You can easily change this to pass in the stuff as string scalars instead.

To use:

require cvsLogin.pl;
require services.pl;

&_cvsLogin( $target );


cat >cvsLogin.pl repository();
  my $cmd = "export CVS_PASSFILE=$workDir/.cvspass; cvs -d $repository login";
  my @input = ( $target->userpw() );
  my ($i,$j) = &logTick( $cmd, $target->buildlog(), \@input, 0);
}
EOF


cat >services.pl add(*KIDSTDOUT,*KIDSTDERR);
print KIDSTDIN join("\n", @$input ), "\n";
push(@$output, &getsome( $selector, 0.25 ) );

$selector->remove(*KIDSTDOUT,*KIDSTDERR);
close(KIDSTDIN);
close(KIDSTDOUT);
close(KIDSTDERR);
waitpid($pid,0);

my $ierr = $? >> 8;
my $isig = $? & 255;
my $msg = "Execution Summary:\n\tCmd=$cmd\n\tRC=$ierr\n\tSignal=$isig\n";
push(@$output,$msg);
if ( $ierr != 0 ) {
  warn($msg) if $logWarnings;
}

return ($ierr,$isig);

#
# no input provided, do it the easy way, with backticks.
#
  } else {
push(@$output,"\n\$$cmd\n");
@foo = `( $cmd )2>&1`;
push(@$output,@foo);

my $ierr = $? >> 8;
my $isig = $? & 255;
my $msg = "Execution Summary:\n\tCmd=$cmd\n\tRC=$ierr\n\tSignal=$isig\n";
push(@$output,$msg);
if ( $ierr != 0 ) {
  warn($msg) if $logWarnings;
}
return ($ierr,$isig);
  }
}


sub getsome {
  my ($selector)=shift;
  my ($wait)=shift || 0.5;

  my $output = "";
  my @output = ();
  my @temp = ();
  my @ready = ();
  my $len = 0;
  my $buf = 0;
  #warn("Getsome checking selector.");
  while ( @ready = $selector->can_read( $wait )) {
#warn( "Getsome has " . (scalar @ready ) . " file handles with waiting data ");
foreach my $fh (@ready) {
  #if (fileno($fh) == fileno(KIDSTDOUT) ) {
#$output =  scalar ;
#warn("calling sysread...");
#$len = sysread( KIDSTDOUT, $buf, 2048, 0 );
$len = sysread( $fh, $buf, 2048, 0 );
#warn( "GOT $len bytes: ", $buf );
$output .= $buf ;
 # }
  if ( $len == 0 ) {
#warn( "EOF on filehandle detected, removed from selector" );
$selector->remove($fh);
  }
}
  }
  @temp = split(/\n/,$output);
  foreach (@temp) {
push(@output,$_ . "\n");
  }
 # push(@output, split(/\n/,$output ));
  #warn("Getsome exiting");
  return @output ;
}

1;

=back

=head1 AUTHOR

Joi Ellis

=head1 BUGS

Undoubtedly.

=head1 REPORTING BUGS

Send Email to Joi Ellis E[EMAIL PROTECTED].

=head1 COPYRIGHT

Copyright © Aravox Technologies, Inc.

=head1 SEE ALSO

see-also links goes here

EOF


-- 
Joi EllisSoftware Engineer
Aravox Technologies  [EMAIL PROTECTED], [EMAIL PROTECTED]

No matter what we think of Linux versus FreeBSD, etc., the one thing I
really like about Linux is that it has Microsoft worried.  Anything
that kicks a monopoly in the pants has got to be good for something.
   - Chris Johnson


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

Re: Moving CVS repository

[Gianni Mariani]

Eric Siegerman wrote:

>On Wed, May 01, 2002 at 01:42:44PM -0500, Joi Ellis wrote:
>
>>  find . -type f -name 'Root' | \
>> xargs perl -pi.bak -e 's/localhost/some.hostname/'
>>[...]
>>I prefer using perl rather than a 'cp' because some of our modules
>>are nested and I don't trust the Root file to be identical all
>>through the tree.  Maybe they are, maybe they aren't.
>>
we have a rule in our base Makefile that fiddles with the file - and 
this works only on CVS Root files.

.PHONY: fix_root
fix_root: CVS/Root
if [ X`cat $<` = X$(OLD_ROOT) ]; then echo $(NEW_ROOT) > $<; fi

It's policy to have a Makefile that includes our base make file in every 
directory.




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

Re: Moving CVS repository

[Eric Siegerman]

On Wed, May 01, 2002 at 01:42:44PM -0500, Joi Ellis wrote:
>   find . -type f -name 'Root' | \
>  xargs perl -pi.bak -e 's/localhost/some.hostname/'
> [...]
> I prefer using perl rather than a 'cp' because some of our modules
> are nested and I don't trust the Root file to be identical all
> through the tree.  Maybe they are, maybe they aren't.

Agreed.

> It also makes it easier to repair damage should some foolish programmer
> have a file named 'Root' with other content.

The way to guard against that is to be more careful with the
first, "selection", part of the pipeline, rather than the last,
"action" part:
find . -type f -print | grep '/CVS/Root$' | xargs [whatever]

The "whatever" can be perl, cp, or anything else that makes sense
(though I typically use perl, as shown above).

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
Anyone who swims with the current will reach the big music steamship;
whoever swims against the current will perhaps reach the source.
- Paul Schneider-Esleben

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

[OT] Example for Perlwrapper around cvs login?

[Oliver Fischer]

Sorry, may be a little bit offtopic...

Does someone have example perl script to wrap cvs login via open2/3
and IO::Select? I am not able to get my one working.

Thanks...


Oliver



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

Re: determining versions on checkin

[Larry Jones]

David A Uebele writes:
> 
> The problem I'm having is that I'd like to use remote cvs, and
> so accessing the CVS/Entries file is no longer feasible.
> I'm looking for suggestions about other ways to capture
> the version of a file just checked in.

I believe you can use "cvs -n status".

-Larry Jones

When I want an editorial, I'll ASK for it! -- Calvin

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

running apache scripts linked with loginfo / commitinfo

[Arcin Bozkurt]

Hi everyone,

I am trying to run the apache  scripts available at: 
http://cvs.apache.org/viewcvs.cgi/CVSROOT/

as you may guess/know, these scripts are linked with commitinfo,
loginfo, etc.

--

I tried to run this these on our system. The server is a Sun Solaris
running cvs 1.11.1p1. The server runs perl, version 5.005_03 built for
sun4-solaris. 

The client is a Linux Redhat 7.2 running  cvs 1.11.1p1. 

Unfortunately scripts don't work properly.

The scripts are running fine, but i believe one of the function does not
do what it is intended to do. Here is a snippet from that function 

sub change_summary {
local($out, @filenames) = @_;
local(@revline);
local($file, $rev, $rcsfile, $line);

while (@filenames) {
[...]
>>
open(RCS, "-|") || exec 'cvs', '-Qn', 'status', $file;
<<

while () {

if (/^[ \t]*Repository revision/) {
chomp;
@revline = split(' ', $_);
$rev = $revline[2];
$rcsfile = $revline[3];
$rcsfile =~ s,^$CVSROOT/,,;
$rcsfile =~ s/,v$//;
}
}
close(RCS);

[...]
}

The line marked (open(RCS, ..)) executes cvs -Qn status $file on the
server. But CVS does not return any information when you try to execute
this because it complains that it doesn't know about any CVS/Entries
file. Because cvs status works only on a checked out copy. Since there
is no such thing on the server, how can we expect this to work??

I believe there are some other problem associated with this scripts. It
sends 2 files as an email. One has just the time/dat info, the other has
a listing of the changed/renamed/added etc file with no summary info (no
summary info because CVS status call does not work)


--

What I have written above is my understanding of what is going on. If
you have worked with these apache scripts, can you help me to make them
work ?

Any help is greatly appreciated.

-arcin


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