Re: Repairing repository

2002-07-30 Thread Mike Pumford

 
   The device upon which my repository was stored has failed.  I have last week's 
 backup, but I had done some checkins since then.  Fortunately, I have an up to 
 date tree.  I have copied the backup in to create a new repository.  Now I 
 must identify the files in the current working tree which are newer than 
 (different from) the files in the repository, and get them comitted.  Any 
 suggestions for the easy way to do this?
 
 
Whatever you do don't do a cvs update. If your local revision is != to the
revision in the CVS repository CVS will update it with the repository version 
potentially losing a lot of changes.

My advice for dealing with this is:

1 backup your local working directory.

2 Get a modified CVS which will report an error if the revision number in
  the repository is less than the one in the working directory (I can supply 
  a source patch for this if you want and possibly a binary).

3 Use the modified client to identify local files that have a revision number
  greater than the repository revision. 

4 For each of these files adjust the revision number in CVS/Entries to match
  the revision number in the repository

5 Once you have sorted out all the CVS/Entries files you should be able to
  commit and bring the repository and your workspace back in sync at the
  cost of a little file history.
 

Mike 



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



CVS bug? Committing a new file to a branch failed and the local file was cleared!

2002-07-30 Thread Reinstein, Shlomo

Hi,

A user checked-out a CVS project from a branch, modified it, added a file,
and then tried to commit. When he committed, he saw output like the
following:
(I deliberately changed the names of the files and paths, note the problem
with file2.c below)

...
repository-path/Proj/file1.c,v  --  file1.c
new revision: 1.5.2.1; previous revision: 1.5
done
RCS file: repository-path/Proj/Attic/file2.c,v
done
cvs commit: cannot remove file2.c: Permission denied
cvs [commit aborted]: cannot rename file CVS/,,file2.c to file2.c: File
exists

C:\working-directory cvs status Proj/file2.c
===
File: file2.c Status: Locally Added

   Working revision:New file!
   Repository revision: No revision control file
   Sticky Tag:  branch_v82 - MISSING from RCS file!
   Sticky Date: (none)
   Sticky Options:  (none)


Looking at the repository, file2.c,v exists, and it has some admin
information but no contents (trying to do co file2.c,v to a temporary
directory yields a 0-size file). Also, the local copy of this file (from
which it was committed) has been cleared. The local file still exists, but
has the size 0.

Shlomo

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



Query about using multiple CVSROOT's

2002-07-30 Thread srijit lahiri

Hello,

We are using multiple CVSROOT's for a particular cvs
server. 

I have configured the inetd.conf file through a script
to allow access to multiple roots.

However, users having access to more than one
CVSROOT's are not being able to login into more than
one CVSROOT's. After the first successful login into a
CVSROOT all successive attemps to login into other
CVSROOT's are existed with the message :

authorization failed: server host rejected access to
/abc/xyz for user cvsuser

although cvsuser is a valid entry in the passwd of
/abc/xyz also.

But other users entries in the passwd file of /abc/xyz
could login as usual.

My query is, is there some restriction on the number
of CVSROOT values that a particular user could be
registered with ?

Thanks in advance.

Best Regards
Srijit Lahiri.


__
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

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



ftp location for CVS mailing list archives

2002-07-30 Thread Johnson, Susan

Is there an ftp location where I could download the
CVS mailing list archives?

I prefer to grep archives rather than use a search
engine like webcrawler.

Thank you.

Susan Johnson

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



RE: Repairing repository

2002-07-30 Thread Bill

Whatever you do, make sure you use tags liberally.  You should tag the whole
repository before you start and after you are done.  You should probably
also add tags in stages as you are going along.  It will pay off when you
find you committed something that was not merged properly.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Eric Siegerman
Sent: Monday, July 29, 2002 15:38
To: [EMAIL PROTECTED]
Subject: Re: Repairing repository


On Mon, Jul 29, 2002 at 02:40:05PM -0400, Matt Riechers wrote:
 [EMAIL PROTECTED] wrote:
 
  I have copied the backup in to create a new repository.  Now I
  must identify the files in the current working tree which are newer than
  (different from) the files in the repository, and get them comitted.
Any
  suggestions for the easy way to do this?

 What's wrong with 'cvs update/commit'?

Lots!  The sandbox's state information doesn't correspond with
the restored repo.  I don't know what the results will be, but it
could get ugly.

Look in the archives of this list for my message of July 4, 2002,
with the subject cvs repository confusion.  That addresses a
slightly different situation, but you should be able to adapt it
to your needs.  If you have further questions, feel free to ask.

--

|  | /\
|-_|/ 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


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



Quick 'how to' question about modules ...

2002-07-30 Thread Marc G. Fournier


Not sure if this is possible or not, and would appreciate a pointer to a
doc if it is ...

I have three modules:

moduleA
bin/moduleB
bin/moduleC

I'd like to make an 'alias' or something that, if I check out moduleA, it
will include B and C as subdirectories.  ie:

moduleA/src/bin/moduleB
moduleA/src/bin/moduleC

is this possible?  so far, I haven't found anything that says it is, so it
just may be wishful thinking ... but figured I'd ask ...


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



Working with FP import

2002-07-30 Thread Patrick Nelson

I have a customer who I want me to implement cvs so they can get in control
of their web development.  The problem that I have come up with is that
their web site is developed with ms Front Page.  FP has these index
directories with text files in them which have names like the files in the
parent directory.  So, I have file that are binary and a matching file that
is text like:

  MyLovely.jpg
  vti_cnf/MyLovely.jpg

The MyLovely.jpg is the image file and vti_cnf/MyLovely.jpg is the text
file.  The problem comes with importing this.  I have do a very slow and
manual process to do this by hand.  I was wondering if there is a way or if
someone has a process to handle this kind of situation.

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



Re: ftp location for CVS mailing list archives

2002-07-30 Thread Mike Ayers


Yep!  L(.)(.)k here--+
  |
Johnson, Susan wrote:|
 Is there an ftp location where I could download the|
 CVS mailing list archives? |
|
 I prefer to grep archives rather than use a search   |
 engine like webcrawler.|
|
 Thank you. |
|
 Susan Johnson  |
|
 ___|
 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: CVS bug? Committing a new file to a branch failed and the local f ile was cleared!

2002-07-30 Thread Eric Siegerman

On Tue, Jul 30, 2002 at 11:52:44AM +0300, Reinstein, Shlomo wrote:
 cvs commit: cannot remove file2.c: Permission denied
 cvs [commit aborted]: cannot rename file CVS/,,file2.c to file2.c: File
 exists

These are the key.  (Especially the first one; the second error
just confirms which copy of file2.c the first error occurred on.)
CVS was trying to replace the sandbox copy of the file with
another copy it had created, and was unable to do so.

(I don't know why it wanted to do this; since it hadn't yet
committed a revision, it seems too early to have been doing
keyword expansion.  But that's immaterial; what matters is that
it tried, and failed.)

Now, as to why it failed.  The error is Permission denied.  You
don't say which operating system, (or, for that matter, which CVS
version).  If the sandbox lives on a UNIX machine, then the
problem would appear to be that the user has no write permission
in file2.c's parent directory.  How the user created the file in
the first place, I'm not sure.  Maybe the directory was chmod'ed
afterward?  Maybe it's chmod'ed like /tmp on many systems --
drwxrwxrwt -- and owned by someone other than the user in
question?  Dunno, but that's a simple UNIX thing.

If the sandbox is on an NT machine (or worse, if it's on a
remote-mounted file system of some sort), I can't offer any
further thoughts.

--

|  | /\
|-_|/ 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: Repairing repository

2002-07-30 Thread Eric Siegerman

On Tue, Jul 30, 2002 at 09:05:08AM -0400, Bill wrote:
 Whatever you do, make sure you use tags liberally.

Emphatically seconded!

--

|  | /\
|-_|/ 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: Working with FP import

2002-07-30 Thread Eric Siegerman

On Tue, Jul 30, 2002 at 09:35:50AM -0700, Patrick Nelson wrote:
 ms Front Page [...] has these index
 directories with text files in them which have names like the files in the
 parent directory.  So, I have file that are binary and a matching file that
 is text like:
 
   MyLovely.jpg
   vti_cnf/MyLovely.jpg

I can only think of a kludge: add a .cvswrappers to each vti_cnf
directory that labels *everything* as text.  This'll work, but
it's fragile, since a user has to remember to do it every time
they add a new directory -- and I'm sure FrontPage carefully
hides the vti_cnf subdirectories from users.

On the other hand, what's the harm in checking in the vti_cnf
files as binary?  If they're only used by FrontPage:
  - they don't have CVS keywords to be expanded
  - they're only used under Windows, so who cares if they come
out on UNIX boxes with extra ^M's?

On the other other hand, what happens if you simply don't check
in the vti_cnf files at all -- just put vti_cnf in
CVSROOT/cvsignore?  That might break FP completely ...  or it
might only break it in an acceptably minor way :-)

--

|  | /\
|-_|/ 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



Newbie Q: cannot open CVS/Entries for reading

2002-07-30 Thread Albin Takami

Hi,

I'm trying to make CVS work on our HP-UX 11.0 network.

1. Downloaded CVS and installed it.
2. Specified CVSROOT in .cshrc
3. Created a repository with cvs init
4. Checked in/committed a bunch of files with cvs ci *.v
5. I setup the .cshrc file for another user, Peggy.
6. Peggy tried to check in some files using the same command as I did (cvs
ci *.v), and that's when she got below error message.

cvs commit: cannot open CVS/Entries for reading: No such file or directory
cvs commit: nothing known about `abc.v'
cvs commit: nothing known about `def.v'

Please let me know what I do wrong.

Thanks,
Albin



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



Re: Repairing repository

2002-07-30 Thread Mike Ayers


Okay, here's how I restored my repository from a recent archive of the 
repository itself and a good working tree (sandbox).  Thanks to all 
who responded - I couldn't have done it without you.

First, all work is done on copies of the archive and the sandbox. 
Whenever I made a mistake, I just erased my working copies and started 
over.

1.  Copy the archive to the new[1] location.  Call this the restored 
archive.

2.  Copy the sandbox to a new location.  Call this the preserved sandbox.

2.  In a new location, check out a sandbox from the archive.  Call this 
the restored sandbox.

3.  Delete everything from the restored sandbox that isn't a CVS admin 
file:

$ find . -type f | grep -v '/CVS/' | sed 's/^/\/' | sed 's/$/\/' | 
xargs rm

(the sed scripts enclose the filename in quotes to handle paths with 
spaces in them, which I had)

4.  Delete everything from the preserved sandbox that is a CVS admin file:

$ find . -type d -name CVS | sed 's/^/\/' | sed 's/$/\/' | xargs rm -rf

5.  Copy the preserved sandbox onto the restored sandbox:

$ cd /restored/sandbox
$ cp -R /preserved/sandbox/* .

6.  Do a `cvs update` on the restored sandbox.  This should reduce the 
differences to the files which are actually different, and mark those 
files commitable.

7.  Check the commitable files to ensure that they look like the ones 
in the preserved sandbox.

8.  Commit all the commitable files, using a comment which is the same 
for all of them, and which can be used to find them.  Optionally, tag 
them as well.

9.  Check out a new sandbox.  Other than the loss of some tags and 
commit comments, you should have your original archive back.  (Note: 
I put this step in because I found that the read-only bits on the 
files in the restored sandbox were inconsistent after the restoration).


That's it.  This is basically the method suggested by Eric Siegerman 
with a few modifications.  Hope it helps.


/|/|ike


[1] - Due to the nature of my archive failure, I could not restore my 
archive to its old location.  It makes no difference, though.


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



How I repaired my repository

2002-07-30 Thread Mike Ayers


[Note: this is an update.  There were two steps I forgot]

Okay, here's how I restored my repository from a recent archive of the 
repository itself and a good working tree
(sandbox).  Thanks to all who responded - I couldn't have done
it without you.

First, all work is done on copies of the archive and the sandbox. 
Whenever I made a mistake, I just erased my working
copies and started over.

1.  Copy the archive to the new[1] location.  Call this the restored 
archive.

2.  Copy the sandbox to a new location.  Call this the preserved sandbox.

2.  In a new location, check out a sandbox from the archive.  Call this 
the restored sandbox.

3.  Delete everything from the restored sandbox that isn't a CVS admin 
file:

$ find . -type f | grep -v '/CVS/' | sed 's/^/\/' | sed 's/$/\/' |
xargs rm

(the sed scripts enclose the filename in quotes to handle paths with
spaces in them, which I had)

4.  Delete everything from the preserved sandbox that is a CVS admin file:

$ find . -type d -name CVS | sed 's/^/\/' | sed 's/$/\/' | xargs rm -rf

5.  Copy the preserved sandbox onto the restored sandbox:

$ cd /restored/sandbox
$ cp -R /preserved/sandbox/* .

6.  Do a `cvs update` on the restored sandbox.  This should reduce the 
differences to the files which are actually different,
and mark those files commitable.

7.  Check the commitable files to ensure that they look like the ones 
in the preserved sandbox.

8.  Now step through your archives and find all the directories which 
do not exist in the restored repository and should.
I do not know how to do this on the command line, as I am using
WinCVS, which makes this step quite easy.

9.  Add any files in the directories discovered in Step 8 to
the restored repository.

10.  Commit all the commitable files, using a comment which is the same 
for all of them, and which can be used to find them.
Optionally, tag them as well.

11.  Check out a new sandbox.  Other than the loss of some tags and 
commit comments, you should have your original archive back.
(Note: I put this step in because I found that the read-only bits on
the files in the restored sandbox were inconsistent after the
restoration).


That's it.  This is basically the method suggested by Eric Siegerman 
with a few modifications.  Hope it helps.


/|/|ike


[1] - Due to the nature of my archive failure, I could not restore my
archive to its old location.  It makes no difference, though.



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



Re: How I repaired my repository

2002-07-30 Thread Eric Siegerman

Glad to hear you've recovered!

On Tue, Jul 30, 2002 at 11:11:37AM -0700, Mike Ayers wrote:
   That's it.  This is basically the method suggested by Eric Siegerman 
 with a few modifications.

Yup, pretty much the same modifications I'd have made :-)


 $ find . -type f | grep -v '/CVS/' | sed 's/^/\/' | sed 's/$/\/' |
 xargs rm
 
 (the sed scripts enclose the filename in quotes to handle paths with
 spaces in them, which I had)

You can do both of those in one sed script with:
... | sed 's/.*//' | ...
Though I'd use single quotes instead:
... | sed s/.*/''/ | ...
to protect against other shell-sensitive characters that aren't
disabled by double quotes -- '$' for example.

Even better is to use GNU find and xargs, both of which are parts
of their findutils package, since those provide a way to
completely avoid the problem:
find DIRS -CRITERIA -print0 | xargs -0 COMMAND
That separates the pathnames with '\0's instead of newlines, and
causes xargs to look for same.


   6.  Do a `cvs update` on the restored sandbox.  This should reduce the 
 differences to the files which are actually different,
 and mark those files commitable.

Hmm, I'd have done a cvs -n update first, looking for anything
unusual, i.e. other than M and ? lines, before trusting a
real update not to make a mess:
  - If there are files reported as lost, you need to
cvs remove them

  - There shouldn't be any conflicts, given the situation, but if
there are, this is a case where CVS's automatic merge will
NOT do the right thing.

  - Likewise any files reported as U but not as lost.  Again,
this shouldn't occur -- which is why I *really* want to know
if it does!

Think of this sanity checking as the manual equivalent of
assert()'s :-)


   8.  Now step through your archives and find all the directories which 
 do not exist in the restored repository and should.
 I do not know how to do this on the command line, as I am using
 WinCVS, which makes this step quite easy.

You can do this iteratively using CVS:
  - do cvs -nq update and look for the ? lines
  - cvs add those
  - repeat until there aren't any more ?s

You can't reduce it to a single pipeline per pass:
cvs -nq update | sed 'some magic or other' | xargs cvs add
That doesn't work, especially in client/server mode, if the files
being added are in multiple directories.  (Rather, it used not to
work; maybe it does now...)

The multiple passes are because, if a directory is new, its
contents won't show up as ? lines until you've cvs added the
directory itself.


 Optionally, tag them as well.

I wouldn't consider this optional, but that's personal preference
of course :-)

--

|  | /\
|-_|/ 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: CVS bug? Committing a new file to a branch failed and the local f ile was cleared!

2002-07-30 Thread Reinstein, Shlomo

The user was working in Windows 2000, CVS version 1.10.7. The keyword
expansion is a good point - I now understand why a commit operation changes
the local copy of the file. This is problematic, though - because the user
was left with an empty file - both locally and in the repository, and there
was no way to restore it; you must be right that CVS should first commit the
file and only then modify the local copy, even just to prevent such cases.
Thanks,
Shlomo


-Original Message-
From: Eric Siegerman [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 30, 2002 8:04 PM
To: '[EMAIL PROTECTED]'
Subject: Re: CVS bug? Committing a new file to a branch failed and the local
f ile was cleared!


On Tue, Jul 30, 2002 at 11:52:44AM +0300, Reinstein, Shlomo wrote:
 cvs commit: cannot remove file2.c: Permission denied
 cvs [commit aborted]: cannot rename file CVS/,,file2.c to file2.c: File
 exists

These are the key.  (Especially the first one; the second error
just confirms which copy of file2.c the first error occurred on.)
CVS was trying to replace the sandbox copy of the file with
another copy it had created, and was unable to do so.

(I don't know why it wanted to do this; since it hadn't yet
committed a revision, it seems too early to have been doing
keyword expansion.  But that's immaterial; what matters is that
it tried, and failed.)

Now, as to why it failed.  The error is Permission denied.  You
don't say which operating system, (or, for that matter, which CVS
version).  If the sandbox lives on a UNIX machine, then the
problem would appear to be that the user has no write permission
in file2.c's parent directory.  How the user created the file in
the first place, I'm not sure.  Maybe the directory was chmod'ed
afterward?  Maybe it's chmod'ed like /tmp on many systems --
drwxrwxrwt -- and owned by someone other than the user in
question?  Dunno, but that's a simple UNIX thing.

If the sandbox is on an NT machine (or worse, if it's on a
remote-mounted file system of some sort), I can't offer any
further thoughts.

--

|  | /\
|-_|/ 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

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



(no subject)

2002-07-30 Thread Josh


 As I am running the CVS server (v1.11.2 pserver) on a 
 (linux) machine with two network adapters I would very 
 much like to know if it is possible to bind the server 
 to a specific network interface?

 e.g.
   eth0: dyn-ip
   eth1: dyn-ip

 With the server only listening on the 'eth1' interface?
 

 Thanks, J.


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



Re: (no subject)

2002-07-30 Thread Gianni Mariani


You can do this using ip filtering.  Check out ipchains or iptables 
which is OT.

Regards
G

Josh wrote:

 As I am running the CVS server (v1.11.2 pserver) on a 
 (linux) machine with two network adapters I would very 
 much like to know if it is possible to bind the server 
 to a specific network interface?

 e.g.
   eth0: dyn-ip
   eth1: dyn-ip

 With the server only listening on the 'eth1' interface?
 

 Thanks, J.


___
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