moving modules from one repository to another with all details

[Sudarshan]

hi

i have created a repository in /projects. where i had a module called
projsudhi.
which i have subjected to lot of changes.
now i want to move that module to new cvs root under /projects/project2
not as the new module but with the module which has all the earlier
modifications into it from the old cvs repository .  I want  all the
informations to be as it is. how should i do that.
o/s- redhat7.0
cvs -1.10.8-8


thanking  in advance

sudarshan




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

RE: Latest core CVS source

[Ross Smith]

> From: Larry Jones
> > 
> > After running make, which reruns aclocal, autoconf, (automake?) and ./configure, I 
>tried running 'cvs diff -u', but I get
> > "connection reset by peer".
> 
> That indicates a (hopefully) temporary server problem -- please try it
> again.  What I want to know is how the results of rerunning that stuff
> is different from what's in the repository.

I've attached the file.  It's huge.  I can't begin to figure out what's happened.

Good luck and let me know if you come up with a solution.

I'd be happy to attempt anything you suggest.

-Ross

 after_make.diff

Re: jailing list!

[Larry Jones]

mm rao writes:
> 
> I would like to be in the CVS-Info mailing list.
> Please add me or tell me hoe to subscribe.

It's in the headers of every message (although you may have to beat your
mailer to get it to show you all the headers):

> List-Subscribe: ,
>   

-Larry Jones

Rats.  I can't tell my gum from my Silly Putty. -- Calvin

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

Re: Latest core CVS source

[Larry Jones]

Laine Stump writes:
> 
> [EMAIL PROTECTED] (Larry Jones) writes:
> 
> > That's because when you check things out of CVS, the files' timestamps
> > are set to the current time rather than the time they were committed
> > (for good reason)
> 
> I thought that was only the case for updates, not for checkout. The
> initial checkout gives files the timestamp of the commit for the
> revision being checked out.

Right you are.  Can you tell I don't do checkout very often?  :-) 
Because regenerating those files doesn't necessarily change the
contents, a simple commit won't update the repository and thus the files
currently in the repository don't have the correct timestamps to avoid
make trying to regenerate them.  That's something we'll have to take
care of before making a new release.  In the meantime, the following:

touch aclocal.m4 stamp-h1.in config.h.in Makefile.in configure

should be sufficient to get make to carry on with the real work without
trying to regenerate stuff it doesn't need to.

-Larry Jones

Nothing spoils fun like finding out it builds character. -- Calvin

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

jailing list!

[mm rao]

I would like to be in the CVS-Info mailing list.
Please add me or tell me hoe to subscribe.
_Thanks
-MM

__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

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

Re: CVS setup

[Larry Jones]

Eric Siegerman writes:
> 
> On Fri, Apr 06, 2001 at 03:00:37PM -0400, Larry Jones wrote:
> > 
> > (Actually, all you need is GNU xargs:
> > 
> > find . -print | tr '\n' '\0' | xargs -0 ...
> 
> Well, GNU's find and xargs are distributed in the same package
> (findutils), so this shouldn't be too much of an issue :-)

True.  The unstated benefit (which was perhaps a bit too subtle) is that
it can be quite handy to do other line-oriented things (like grep, for
example) between the find and the tr.

-Larry Jones

OK, what's the NEXT amendment say?  I know it's in here someplace. -- Calvin

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

Re: CVS setup

[Eric Siegerman]

On Fri, Apr 06, 2001 at 03:00:37PM -0400, Larry Jones wrote:
> You can if you have the GNU versions of find and xargs:
> 
>   find . -print0 | xargs -0 ...
> 
> (Actually, all you need is GNU xargs:
> 
>   find . -print | tr '\n' '\0' | xargs -0 ...

Well, GNU's find and xargs are distributed in the same package
(findutils), so this shouldn't be too much of an issue :-)

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)

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

Re: Latest core CVS source

[Laine Stump]

[EMAIL PROTECTED] (Larry Jones) writes:

> That's because when you check things out of CVS, the files' timestamps
> are set to the current time rather than the time they were committed
> (for good reason)

I thought that was only the case for updates, not for checkout. The
initial checkout gives files the timestamp of the commit for the
revision being checked out.

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

Re: CVS setup

[Laine Stump]

[EMAIL PROTECTED] (Larry Jones) writes:

> Laine Stump writes:
> > 
> > Yes, the unfortunate part is that InstallShield insists on using long
> > names with embedded spaces for directories and files, which leads to
> > odd inconveniences occasionally (eg, cvs -n update doesn't work
> > properly, 
> 
> What goes wrong?

When I look at it more closely, I find:

1) It's not that big a deal.
2) it probably occurs when the directory names *don't* have spaces, too.
   (I just happened to notice it in a directory that had spaces in the name,
   and made a rash assumption).

What I saw was a message like this:

cvs update: New directory `ishield/Setup Files/Compressed Files/0009-English/Intel 32' 
-- ignored

When the given directory is in the repository but empty (and I have -P
in my .cvsrc, ie the directory doesn't exist in my workspace).

When I do update without -n, no message about the empty directory is
printed. It seems like "-n update" should notice that the directory is
empty and -P is on, and print nothing. But, as I said, it's not a big
deal.

> > you can't use "find . -print | xargs ...", etc).
> 
> You can if you have the GNU versions of find and xargs:
> 
>   find . -print0 | xargs -0 ...
> 
> (Actually, all you need is GNU xargs:
> 
>   find . -print | tr '\n' '\0' | xargs -0 ...
> 
> although various versions of tr have slightly different syntaxes, so you
> might have to fool around a bit to get exactly the right incantation.)

Cool! Now that you say it, I think I remember seeing that before, but
it didn't stick with me then because I didn't need it. After this,
I promise I'll remember it! ;-)

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

Re: CVS setup

[Larry Jones]

Laine Stump writes:
> 
> Yes, the unfortunate part is that InstallShield insists on using long
> names with embedded spaces for directories and files, which leads to
> odd inconveniences occasionally (eg, cvs -n update doesn't work
> properly, 

What goes wrong?

> you can't use "find . -print | xargs ...", etc).

You can if you have the GNU versions of find and xargs:

find . -print0 | xargs -0 ...

(Actually, all you need is GNU xargs:

find . -print | tr '\n' '\0' | xargs -0 ...

although various versions of tr have slightly different syntaxes, so you
might have to fool around a bit to get exactly the right incantation.)

-Larry Jones

We don't ATTEND parties, we just CRASH 'em. -- Calvin

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

Re: EDITOR

[Larry Jones]

cherry Jacky writes:
> 
> I have set both $CVSEDITOR and $VISUAL in my
> working environment to vi.  I was expecting to see a
> vi editor shows up when I commit a file but I didn't. 

What happened instead -- did you get a different editor, were you
prompted to enter a log message, or did it just complete without any
prompt at all?  It's possible that there's a default message or a
different editor specified in your ~/.cvsrc file.  It's also possible
that there's a $CVSROOT/CVSROOT/editinfo file that specifies a different
editor.

-Larry Jones

I always have to help Dad establish the proper context. -- Calvin

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

Re: EDITOR

[Ashley M. Kirchner]

cherry Jacky wrote:

> %setenv CVSEDITOR vi

Try 'setenv EDITOR vi' (although this will change your global value,
so that it applies to everything calling the $EDITOR variable, not just
CVS)

AMK4

--
W |
  |  I haven't lost my mind; it's backed up on tape somewhere.
  |
  ~
  Ashley M. Kirchner    .   303.442.6410 x130
  SysAdmin / Websmith   . 800.441.3873 x130
  Photo Craft Laboratories, Inc. .eFax 248.671.0909
  http://www.pcraft.com  . 3550 Arapahoe Ave #6
  .. .  .  . .   Boulder, CO 80303, USA



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

Re: CVS setup

[Laine Stump]

Jerry Nairn <[EMAIL PROTECTED]> writes:

> Also worth mentioning in this thread is the fact that most of the files
> generated by InstallShield and the associated tool, Package for the Web, are
> ordinary text.

Yes, the unfortunate part is that InstallShield insists on using long
names with embedded spaces for directories and files, which leads to
odd inconveniences occasionally (eg, cvs -n update doesn't work
properly, you can't use "find . -print | xargs ...", etc).

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

Re: Latest core CVS source

[Larry Jones]

Ross Smith writes:
> 
> Right.  On a pristine ccvs, I ran ./configure.  Then I ran make and it complains and 
>wants to rerun ./configure (see Listing 1).  Go
> figure.

That's because when you check things out of CVS, the files' timestamps
are set to the current time rather than the time they were committed
(for good reason) so it looks to make like the generated files are
out-of-date with respect to their source files and so it tries to
regerate them.  It appears that the regeneration is not working
correctly for some reason.

> BTW, the same thing happens on another Debian 2.2r0 box as well, so it's not the box 
>being mis-configured.

No, I'm sure it's not; it's almost certainly some kind of automake
problem.

> Well, I've successfullly built apache, doxygen, graphviz, kerberos, lyx, mod_perl, 
>mod_ssl, mysql, php, ssl, ssh, tcl, tk, & wine on
> this box without any problems.  I've also built several packages (apache, mysql, 
>ssl, ssh, etc.) using 'apt-get --compile source'.
> Again, no problems.

I'm sure that's true; Derek found a number of problems with automake and
made a number of enhancements to get it to handle CVS.  For a while,
there was no publicly-available version of automake that handled CVS
correctly, just his private version.  He was working closely with the
automake maintainers, so I expect that that is no longer true, but I
wouldn't expect anything other than the very latest (perhaps even beta)
release would work right.  It's entirely possible that there's a missing
version check that's allowing an earlier version to run and screw things
up.

> > Could you do a ``cvs diff -u'' on the source tree
> > and send the results to info-cvs so we can
> > figure out what's going wrong?
> 
> At what point?
> 
> After ./configure, 'cvs diff -u' reports no changes.
> 
> After running make, which reruns aclocal, autoconf, (automake?) and ./configure, I 
>tried running 'cvs diff -u', but I get
> "connection reset by peer".

That indicates a (hopefully) temporary server problem -- please try it
again.  What I want to know is how the results of rerunning that stuff
is different from what's in the repository.

> > I strongly suspect that if you overwrite your
> > locally-generated copies of the files with the
> > copies from the repository it will build just fine.
> 
> Huh?  I started with a pristine checkout.  So you want me to...
> 
> $ cvs co ccvs
> $ ./configure
> $ cvs up
> $ make
> 
> ?

No, just ./configure and make.  After make fails, run the diff as per
above and then do ``cvs up -C'' to overwrite the locally-modified files
with the files from the repository.  Then re-do the ./configure and
make.  At that point, make should just start compiling instead of
rerunning all the autoconf/automake stuff.

-Larry Jones

Geez, I gotta have a REASON for everything? -- Calvin

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

EDITOR

[cherry Jacky]

Hi all:
I have set both $CVSEDITOR and $VISUAL in my
working environment to vi.  I was expecting to see a
vi editor shows up when I commit a file but I didn't. 
Do I miss something here?  This is what I did.

%
%setenv CVSEDITOR vi
%setenv VISUAL vi
%cvs commit main.C
%
%
%
%



best regards,





__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

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

RE: Latest core CVS source

[Ross Smith]

> From: Larry Jones
>
> It looks like it's rebuilding a bunch of automake/autoconf
> files that shouldn't need to be rebuilt

Right.  On a pristine ccvs, I ran ./configure.  Then I ran make and it complains and 
wants to rerun ./configure (see Listing 1).  Go
figure.

BTW, the same thing happens on another Debian 2.2r0 box as well, so it's not the box 
being mis-configured.

> -- perhaps your installed versions of the
> tools don't handle things the way we expect.

Well, I've successfullly built apache, doxygen, graphviz, kerberos, lyx, mod_perl, 
mod_ssl, mysql, php, ssl, ssh, tcl, tk, & wine on
this box without any problems.  I've also built several packages (apache, mysql, ssl, 
ssh, etc.) using 'apt-get --compile source'.
Again, no problems.

> Could you do a ``cvs diff -u'' on the source tree
> and send the results to info-cvs so we can
> figure out what's going wrong?

At what point?

After ./configure, 'cvs diff -u' reports no changes.

After running make, which reruns aclocal, autoconf, (automake?) and ./configure, I 
tried running 'cvs diff -u', but I get
"connection reset by peer".

> I strongly suspect that if you overwrite your
> locally-generated copies of the files with the
> copies from the repository it will build just fine.

Huh?  I started with a pristine checkout.  So you want me to...

$ cvs co ccvs
$ ./configure
$ cvs up
$ make

?

Thanks for your help,

Ross

Listing 1
-
cd . && /bin/sh /usr/local/src/ccvs/missing --run aclocal
cd . && \
  /bin/sh /usr/local/src/ccvs/missing --run automake --gnu  Makefile
Makefile.am:15: require version 1.4a, only have 1.4
WARNING: `automake' is missing on your system.  You should only need it if
 you modified `Makefile.am', `acinclude.m4' or `configure.in'.
 You might want to install the `Automake' and `Perl' packages.
 Grab them from any GNU archive site.
cd . && /bin/sh /usr/local/src/ccvs/missing --run autoconf
/bin/sh ./config.status --recheck
running /bin/sh ./configure  --no-create --no-recursion
loading cache ./config.cache
checking for a BSD compatible install... (cached) /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for prefix by checking for cvs... (cached) /usr/bin/cvs
checking for mawk... (cached) gawk
checking for gcc... (cached) gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for a BSD compatible install... /usr/bin/install -c
checking whether make sets ${MAKE}... (cached) yes
checking for ranlib... (cached) ranlib
checking for bison... (cached) bison -y
checking whether ln -s works... (cached) yes
checking for perl... (cached) /usr/bin/perl
checking for csh... (cached) no
checking for pr... (cached) /usr/bin/pr
checking for groff... (cached) /usr/bin/groff
checking for ps2pdf... (cached) /usr/bin/ps2pdf
checking for texi2dvi... (cached) /usr/bin/texi2dvi
checking whether #! works in shell scripts... (cached) yes
checking for BSD VPATH bug in make... (cached) no
checking how to run the C preprocessor... (cached) gcc -E
checking for AIX... no
checking for minix/config.h... (cached) no
checking for POSIXized ISC... no
checking for dirent.h that defines DIR... (cached) yes
checking for opendir in -ldir... (cached) no
checking for ANSI C header files... (cached) yes
checking for sys/wait.h that is POSIX.1 compatible... (cached) yes
checking for errno.h... (cached) yes
checking for unistd.h... (cached) yes
checking for string.h... (cached) yes
checking for memory.h... (cached) yes
checking for utime.h... (cached) yes
checking for fcntl.h... (cached) yes
checking for ndbm.h... (cached) no
checking for limits.h... (cached) yes
checking for sys/file.h... (cached) yes
checking for sys/param.h... (cached) yes
checking for sys/select.h... (cached) yes
checking for sys/time.h... (cached) yes
checking for sys/timeb.h... (cached) yes
checking for io.h... (cached) no
checking for direct.h... (cached) no
checking for sys/bsdtypes.h... (cached) no
checking for sys/resource.h... (cached) yes
checking for syslog.h... (cached) yes
checking whether stat file-mode macros are broken... (cached) no
checking whether time.h and sys/time.h may both be included... (cached) yes
checking for working const... (cached) yes
checking for uid_t in sys/types.h... (cached) yes
checking for mode_t... (cached) yes
checking for pid_t... (cached) yes
checking for size_t... (cached) yes
checking return type of signal handlers... (cached) void
checking for st_blksize in struct stat... (cached) yes
checking for st_rdev in struct stat... (cached) yes
checking for mkdir... (cached) yes
checking

Re: CVS setup

[David H. Thornley]

Jerry Nairn wrote:
> 
> Also worth mentioning in this thread is the fact that most of the files
> generated by InstallShield and the associated tool, Package for the Web, are
> ordinary text.
> Jerry

Yes, that's what I was told, and that's one thing that makes
me unwilling to zip everything up and store it in binary.
I'd *much* rather store the text as text.

-- 
David H. Thornley  Software Engineer
at CES International, Inc.:  [EMAIL PROTECTED] or (763)-694-2556
at home: (612)-623-0552 or [EMAIL PROTECTED] or
http://www.visi.com/~thornley/david/

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

RE: CVS setup

[Jerry Nairn]

Also worth mentioning in this thread is the fact that most of the files
generated by InstallShield and the associated tool, Package for the Web, are
ordinary text.
Jerry

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

Re: Getting import tags

[Larry Jones]

Jim Harkins writes:
> 
> How do I get the vendor tag and release tags I used in the original import?

Pick a representative file and do ``cvs status -v'' on it.  The tag for
branch 1.1.1 is the vendor tag and the other tags on that branch are the
release tags.

-Larry Jones

But Mom, frogs are our FRIENDS! -- Calvin

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

Re: Getting import tags

[Stephen Rasku]

Jim Harkins wrote:

>This seems like a silly question that I should be able to get the 
answer to,
>but danged if I see it.  A while ago I imported vendor source code, 
and I've
>been changing said code.  Now the vendor has updated their code, so I 
want
>to import it again.
>
>How do I get the vendor tag and release tags I used in the original 
import?
>

cvs log 

Use README or Changelog or some file that will be in every vendor 
version.  At the top of the log will be a list of the tags and it will 
include the vendor tag and the release tag.

-- 
Stephen Rasku   E-mail: [EMAIL PROTECTED]
Senior Software EngineerWeb:http://www.pop-star.net/
TGI Technologies


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

Getting import tags

[Jim Harkins]

This seems like a silly question that I should be able to get the answer to,
but danged if I see it.  A while ago I imported vendor source code, and I've
been changing said code.  Now the vendor has updated their code, so I want
to import it again.

How do I get the vendor tag and release tags I used in the original import?

jim
[EMAIL PROTECTED]

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

Re: CVS setup

[Larry Jones]

Anders Truelsen writes:
> 
> I've been using CVS to control out install shield setups with spaces and all
> for a couple of years now and I've never experienced any problems.
> Just yesterday I created a bunch of modules with with spaces in their names
> and it seemed to work just fine, though I'm getting slightly worried by now
> :-/

Much (perhaps even most) of CVS is quite happy with spaces in filenames.
Most of the problems are with interfaces to external scripts or things
like the modules file.  As long as you haven't had problems in the past,
you probably won't have problems in the future.  (Note that what you
created were almost certainly top-level directories, not modules. 
Modules are only created by adding things to the CVSROOT/modules file
and since that file is space delimited, it's not possible to create
modules with spaces in their names.)

-Larry Jones

There's never enough time to do all the nothing you want. -- Calvin

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

Re: pserver problems

[Larry Jones]

MOHIT A LAD writes:
> 
> My setup:
> =
> redhat 6.2 kernel2.2.14-12
> cvs1.10.7

I strongly suggest upgrading to the current release (1.11), which you
can get from www.cvshome.org, but that isn't what's causing your
problem.

> 1> export CVSROOT=:pserver:mohit@baharat:/usr/local/cvsdb 
> 2> cvs login - successful
> 3> all other cvs commands return the following error:
> unrecognized auth response from bharat: YPBINDPROC_DOMAIN: Domain not
> bound

You have some kind of an NIS (nee Yellow Pages) problem on the server.
My guess is that you're using NIS for passwords or groups and the server
machine is unable to contact the NIS server for your domain.

> This seems absurd as since the cvs login/logout succeeds the other cvs
> commands should work. 

Not true:  logout is purely client side, it doesn't contact the server
at all.  And for login the server just checks the password and exits, it
doesn't get around to switching to run as the user.

-Larry Jones

Is it too much to ask for an occasional token gesture of appreciation?!
-- Calvin

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

Re: How to fix revision tree?

[Larry Jones]

Nils Jakobson writes:
> 
> Can these unchanged 1.1.1.1-files cause troubles? Is there a way to =
> remove
> the 1.1.1.1 branch or force the file to next trunk revision?

No, that's perfectly normal.  Do a ``cvs status'' on one of the
troublesome files and let us know what it says.

-Larry Jones

I'll be a hulking, surly teen-ager before you know it!! -- Calvin

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

Re: Question about cvsGUI

[Larry Jones]

[EMAIL PROTECTED] writes:
>  
> 3.I get a problem that I can't checkout from server, the message 
> display in the screen is :
>"cvs -q checkout abc (in directory C:\temp\temp\temptest)
> cvs [checkout aborted]: end of file from server (consult 
> above messages if any)

Please upgrade the server to the current release (1.11), which you can
get from www.cvshome.org.  It has much better error reporting.

-Larry Jones

Is it too much to ask for an occasional token gesture of appreciation?!
-- Calvin

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

Re: Latest core CVS source

[Larry Jones]

Ross Smith writes:
> 
> Well, I just CVS'd the latest CVS source and tried to compile it on a
> Debian 2.2r0 system.
> 
> $ ./configure
> $ make
> 
> It fails. (See Listing 1).

It looks like it's rebuilding a bunch of automake/autoconf files that
shouldn't need to be rebuilt -- perhaps your installed versions of the
tools don't handle things the way we expect.  Could you do a ``cvs diff
-u'' on the source tree and send the results to info-cvs so we can
figure out what's going wrong?  I strongly suspect that if you overwrite
your locally-generated copies of the files with the copies from the
repository it will build just fine.

-Larry Jones

Oh, what the heck.  I'll do it. -- Calvin

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

Re: Latest core CVS source

[Larry Jones]

Tony Hoyle writes:
> 
> The makefiles are corrupt (at least on the Linux box I tried it on).  It 
> doesn't even start compiling.  There's also a missing variable 
> (client_active) referenced in 4 or 5 places in the code.

Linux is one of the nightly testing platforms and that works fine, so
I'm not sure what your problem is; could you provide some more details,
please?  As for client_active, I just grepped the src directory and the
only place it appears is in the ChangeLogs -- it sounds like you have
old versions of some files.  Please try a fresh check-out and save the
configure and make output and send them to info-cvs if you still have
problems.

> 'edit -c' has been around for almost 2 years...  The core code looks 
> pretty stagnant if it's that far behind.

There have been at least 223 changes checked in to the src directory in
the last two years, plus changes to other directories as well.  Just
because one particular patch hasn't been incorporated you shouldn't
conclude that nothing's being done.

-Larry Jones

Can I take an ax to school tomorrow for ... um ... show and tell? -- Calvin

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

Re: cvswrappers - any better suggestions ?

[Alexander Kamilewicz]

"David H. Thornley" wrote:
> 
> Here's the situation I'm looking at.
> 
> We do most of our work in conventional programming languages like
> C++ and Java and Perl, and these work very well with CVS. We use
> HTML for some documentation, and that generally works well
> (although I have little experience with CVS storing the abominations
> you get when saving as HTML from Word).  We have things like
> release branches and patch branches.  What this means is that
> CVS works very well for most of the stuff we do.
> 
> On the other hand, there is stuff mixed in there that is not
> source code.  One example would be image files for the HTML.
> These files are most conveniently located in the same directory
> as the HTML files, and in some cases source files.

This is very similar to my environment, although as well as images we
have lots of .mov, .fla, .swf, .doc, .xls, & assorted binary files.

> This means that we have three choices.
> 
> 1.  Continue to use CVS, accepting the problems with binary files.
> 2.  Use a combination of CVS and some other system that handles
> binary files better.
> 3.  Switch to another tool entirely.

We do #1.  The only problem with #1 is that you're going to have a
repository that grows rather rapidly.  We realized that and invested in
a Network Appliance.  My repository is now 33Gb large.

However, since the bulk of our problems with binary files is:  "Here's a
new version of that image/movie/flash/whatever, have fun" we decided
that it would be pointless, at this point, to move to another SCM tool
when CVS fits so well into the toolkit of the developers doing the .htm,
.jsp, and .js files.

I think it's worth noting that one of the pre-eminent SCM tools for
version control/management of images/flash/movies, called MediaWay,
doesn't store "diffs" but stores a copy of every version of every
element ever entered into and/or modified in its repository.

That's basically what CVS does.  So CVS isn't particularly far away from
that functionality.

If you have a need for a tool that provides more and better information
on complex binary files (images/flashes/movies), then you can do what we
do.  Buy MediaWay, have the graphics dudes use it, and use cvs import
when they have new versions.

It works OK for us.

Alex

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

RE: Module variable

[Nick Flowers]

Larry/Laine - 
Thanks for the advice. I did not read the contents of that
URL you sent until Laine's posting. It was just what I needed.
Thanks, Nick.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 04 April 2001 22:40
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Module variable


Laine Stump writes:
> 
> [EMAIL PROTECTED] (Larry Jones) writes:
> > 
> > http://www.cvshome.org/docs/manual/cvs_18.html#SEC171
> 
> My problem with that was that it was (potentially) run as a different
> user each time, resulting in permission errors (since the users don't
> have g+w in their umask). I just wrote a short setuid program that
> executed the same command.

It would have been simpler to add a umask command before the update.

> I also seem to recall that it gets called once for each file, which
> leads to bunches of "waiting for xxx's lock on yyy" messages when a
> single cvs commit ends up committing multiple files (since multiple
> copies of it are running at once).

No, it gets called once per directory.  Since locks are done on a
per-directory basis and the example command sleeps for two seconds
before starting the update (to give the commit time to complete), it
usually isn't a problem, although it might be beneficial to increase the
time delay for a sufficiently large tree.

-Larry Jones

My "C-" firmly establishes me on the cutting edge of the avant-garde.
-- Calvin
E-mail disclaimer:

This message and any attachments are confidential and may be legally
privileged. Any opinion expressed in them may be personal to the author and
may not be shared by ShopSmart Ltd.If you are not the intended recipient you
must not disclose the contents to any other person. Please delete this
message and  any attachments if received in error and e-mail the sender or
contact ShopSmart Ltd on +44 (0) 20 8 208 8800. Thank you.

ShopSmart Ltd, Company No: 03711211
Reg. Address: Britannia Business Centre, Cricklewood Lane, London NW2 1DZ


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

How to fix revision tree?

[Nils Jakobson]

 
Hi, I have cvs1.11 on RedHat with WinCVS clients. 
Problem is that
revisions are messed up, the developer 
buid is not getting latest revisions
of 
many files from repository.
What is strange - many files have their 
first revision 1.1 from which
immediatelly comes branch [ 1.1.1.1 - 
avendor ]- this is only and latest
revision probably since import, but other 
files are ok from beginning - 1.1.
Those 1.1.1.1-files which have been 
changed have revisions going onto 
main
trunk - 1.1 , 1.3 , 1.7 , 
etc... 
Can these unchanged 1.1.1.1-files cause 
troubles? Is there a way to remove
the 1.1.1.1 branch or force the file to next trunk revision?
I'm new to the CVS so probably i have to read more 
- sources are welcome!
 
-Nils
 
 

Question about cvsGUI

[hpcheng]

Dear sir,
I would like to ask you some questions about cvs GUI in NT. The 
following points is my question:
 
1.Have any user guide in details? and where I can dowload?
2.Have any topic is talking of problem solve??
3.I get a problem that I can't checkout from server, the message 
display in the screen is :
   "cvs -q checkout abc (in directory C:\temp\temp\temptest)
cvs [checkout aborted]: end of file from server (consult 
above messages if any)
 
*CVS exited normally with code 1*"

I had imported a module "abc" in the server before,
What can I do in this case?
 Best regards,
Jerry Cheng


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

pserver problems

[MOHIT A LAD]

Hi,

I'm having some problems with the pserver of cvs.

My setup:
=
redhat 6.2 kernel2.2.14-12
cvs1.10.7

On server side:
===
1> following line in /etc/inetd.conf (all on one line) 
cvspserver stream tcp nowait root /usr/bin/cvs cvs 
--allow-root=/usr/local/cvsdb pserver

2>in /etc/services
cvspserver 2401/tcp

3> restarted inetd
4> repository is /usr/local/cvsdb
5> passwd file in /usr/local/cvsdb/CVSROOT has entry for user=mohit
mohit::cvsuser

6> permissions on cvsdb dir:
drwxrwx---3 cvsroot  cvs-rgw  4096 Apr  6 09:42 .

where 'cvsroot' & 'cvsuser' are users on the cvs server machine
'cvs-rgw' is a group which has among others 'mohit' as a user
the group 'cvsuser' & 'cvsroot' have read/write permissions on 'cvsdb'



On client side:
===
1> export CVSROOT=:pserver:mohit@baharat:/usr/local/cvsdb 
2> cvs login - successful
3> all other cvs commands return the following error:
unrecognized auth response from bharat: YPBINDPROC_DOMAIN: Domain not
bound

for example:
[mohit@indrayani]$ cvs -d :pserver:mohit@bharat:/usr/local/cvsdb status
cvs [status aborted]: unrecognized auth response from bharat: 
YPBINDPROC_DOMAIN: Domain not bound

N.B: cvs logout also succeeds

This seems absurd as since the cvs login/logout succeeds the other cvs
commands should work. 


I hope some one can help me soon on this.

Is there a archive of mail-listings or a FAQ where I can additional info
on  cvs problems.

Regards,

Mohit Lad
Tata Infotech Ltd. 
Tel: +91-22-5725018


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