I'm trying to tag a huge file (127MB) on Redhat and am getting the following
error:
cvs [server aborted]: error writing to lock file /myfilename
There is no lock file in the repository, and the filesystem of the
repository has 617 MB of space, and lots of inodes left. There are no
user
We have cvs pserver 1.11.1p1 setup on solaris 2.8 and a wrapper script in
/etc/inetd.conf to allow many --allow-roots (we have many apps/groups/business
units we provide CM support for, thus the need to many repos). We use WinCVS
1.3 for the client.
Currently we have 58 --allow-root options
Well that's weird. I had sent one that didn't seem to post, then sent a
second copy, and now they both show up. I waited several hours before
reposting, honest!
- Original Message -
From: Dustin Puryear [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, December 01, 2003 9:07 AM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark [EMAIL PROTECTED] writes:
We have cvs pserver 1.11.1p1 setup on solaris 2.8 and a wrapper script
in /etc/inetd.conf to allow many --allow-roots (we have many
apps/groups/business units we provide CM support for, thus the need to
many repos).
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dustin Puryear [EMAIL PROTECTED] writes:
I have a project that combines custom software, FreeBSD, and some software
initially grabbed from FreeBSD ports. (We use the FreeBSD ports version
because any FreeBSD-patches to the software have been done
Cary Coulter wrote:
Is there a patch for 1.11.6 CVS for using PAM on Linux for user
authentication? We're using WSAD/Eclipse and understand the 1.11.6
is as new as we can go for now.
I really think you don't want to do this. It is a lot better (a lot more
secure) to use CVS through ssh. I am
Hello,
For any branch but the main one I can refer to latest source code versions
using simply the branch name.
Is there some way (or special tag) which will allow me to refer to the
tips of main branch, so I can use:
cvs diff -r some_branch -r main_branch
Cheers,
Jacek
Is there some way (or special tag) which will allow me to refer to the
tips of main branch, so I can use:
yes, there is a special tag, HEAD
(and another one is BASE, which refers to the revision you last checked
out in your current working directory)
Is there some way (or special tag) which will allow me to refer to the
tips of main branch, so I can use:
yes, there is a special tag, HEAD
(and another one is BASE, which refers to the revision you last checked
out in your current working directory)
So, if I do a cvs checkout without a -r
Dustin Puryear [mailto:[EMAIL PROTECTED] wrote:
Well that's weird. I had sent one that didn't seem to post,
then sent a
second copy, and now they both show up. I waited several hours before
reposting, honest!
Yeah, there seems to have been some delay at gnu.org, judging from the SMTP
headers.
You could consider using xinetd alongside Solaris inetd (just for the CVS
port). It would be a simple experiment to set it up and see if it, too,
exhibits the problem.
[EMAIL PROTECTED] wrote on 12/02/2003
03:38:25 AM:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark [EMAIL PROTECTED]
Thanks for the suggestions Mark.
We actually began importing the distribution version of externally developed
software that we modify (we import as SOFTWARE_VER_DIST), and then we check
in our changes on top of that. I made the decision to not note the version
of the distributed software in the
Andy Jones [mailto:[EMAIL PROTECTED] wrote:
Is there some way (or special tag) which will allow me to
refer to the
tips of main branch, so I can use:
yes, there is a special tag, HEAD
Be aware that with the diff command, HEAD means the head revision of the
currently-checked-out branch
I have tried ssh. It does work, will auth throuch pam_smb_auth using NT
passwords, not Unix ones.
However, I do experience a significant delay when invoking CVS for ssh
authorization (shows on the WSAD dialog box). The delay isn't too bad for
normal repository operations, (synchronizing,
Don't listen to me, listen to Jim! Sorry for the mistake.
So, if I do a cvs checkout without a -r then I get the HEAD revision?
yes.
(only if it is a CLEAN checkout)
And in that case there will be no difference between 'cvs update -j rev1'
and 'cvs update -j rev1 -j HEAD' ?
Is
Hi,
I'm finding this problem a bit hard to explain in a few words, and
aren't having much luck with search engines finding an answer.
I work onsite about half the time and offsite the other half. Some
nights, I'll be onsite, be half way through a complex set of changes,
have heaps of modified
So, if I do a cvs checkout without a -r then I get the HEAD revision?
yes.
And in that case there will be no difference between 'cvs update -j rev1'
and 'cvs update -j rev1 -j HEAD' ?
Is that correct?
yes.
___
Info-cvs mailing list
[EMAIL
Jim.Hyslop writes:
On the other hand, the developers may want to take the current state of the
repository, and assign it a known starting point, such as 2.0. This is
entirely reasonable.
No, it is not. Revision numbers are for CVS's internal use only; people
should ignore them and resist
Mark writes:
Currently we have 58 --allow-root options setup in the wrapper script.
Why do you have so many separate repositories? Can't you just use
modules in a single repository?
Is this a solaris limitation or a cvs limitation (there are about 2513
characters that make up the
[EMAIL PROTECTED] writes:
For any branch but the main one I can refer to latest source code versions
using simply the branch name.
Is there some way (or special tag) which will allow me to refer to the
tips of main branch, so I can use:
cvs diff -r some_branch -r main_branch
For most
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] wrote:
[specifying revision numbers on checkin - is it reasonable?]
No, it is not. Revision numbers are for CVS's internal use
only;
If that's the case, then why was the revision number ever exposed in the
first place? Is it a legacy of RCS or SCCS
Ford, Karen (MED, Contractor) writes:
cvs [server aborted]: error writing to lock file /myfilename
Please don't edit error messages -- quote them verbatim. I'm reasonably
sure that should have been something more along the lines of
,myfilename rather than /myfilename, which would have
Is there just something wrong with the ssh setup? Personally, I have always
experienced a slower login with ssh versus telnet.
Yes, it sounds to me as if something is wrong with your setup. Try running
the ssh server in debug mode, and the client in verbose mode, to see where the
delay comes
Classification: UNCLASSIFIED
-Original Message-
From: Cary Coulter [mailto:[EMAIL PROTECTED]
Is there just something wrong with the ssh setup?
Personally, I have always
experienced a slower login with ssh versus telnet.
you have a slow machine. Telnet does ZERO encryption -
On Tue, Dec 02, 2003 at 08:58:36AM -0600, Cary Coulter wrote:
I have tried ssh. It does work, will auth throuch pam_smb_auth using NT
passwords, not Unix ones.
However, I do experience a significant delay when invoking CVS for ssh
authorization (shows on the WSAD dialog box). The delay
the symbolic branch tag - might just be
easier to use branch tags keyed by date, e.g. priv-craig-transfer-20031202).
2) You can work from the branch, and merge any changes anyone checks in
during the day into your code, and when you're done merge it back to the
trunk. In other words, treat it like
I can't commit the stuff at work (at least to the head
branch), because it's not stable enough (may not even build).
So the obvious answer is: use a branch to do your unstable
commits!
You should do that anyway, because it sounds to be that you are making
changes that go uncommited for a long
keyed by date, e.g. priv-craig-transfer-20031202).
2) You can work from the branch, and merge any changes anyone checks in
during the day into your code, and when you're done merge it back to the
trunk. In other words, treat it like any normal branch.
My inclination would be to use the first approach
I've applied two approaches to address this problem that can be implemented
readily with CVS:
The first method is to use a personal branch for your own development and
periodically merge to the main branch. This is a standard pattern of use
in CVS.
The second is to divorce the notion of
[ On Wednesday, December 3, 2003 at 02:12:59 (+1100), Craig O'Shannessy wrote: ]
Subject: Problems with uncommitted working directories, from home and work.
I never had this problem before, I've been using ssh and vi for years,
but now I'm addicted to an IDE (idea), so I've gotta find a better
[ On Monday, December 1, 2003 at 10:18:19 (-0500), Jim.Hyslop wrote: ]
Subject: RE: CVS Version CHange
On the other hand, the developers may want to take the current state of the
repository, and assign it a known starting point, such as 2.0. This is
entirely reasonable.
No, it's not really.
There are private branches, and there are private branches. In the context
that you describe, the integration branch is private to the builders who
gate the release of the product. Jim refers instead to a branch that's
private to the developer performing the work.
Branches are a general tool
On Tue, Dec 02, 2003 at 11:04:54AM -0700, Larry Lords wrote:
I have a question on Jim's statement Private branches are never considered
candidates for releases or for builds.
The operative word is private.
I have always understood that a company
would always release from a private branch.
[ On Tuesday, December 2, 2003 at 10:47:46 (-0500), Jim.Hyslop wrote: ]
Subject: RE: CVS Version CHange
If that's the case, then why was the revision number ever exposed in the
first place? Is it a legacy of RCS or SCCS - do they not support symbolic
tags?
I don't mean to answer for Larry,
Larry Lords [mailto:[EMAIL PROTECTED] wrote:
I have a question on Jim's statement Private branches are
never considered
candidates for releases or for builds. I have always
understood that a company
would always release from a private branch. This assumes
when a release process
begins
Cary Coulter [EMAIL PROTECTED] writes:
It appears that each time I click on a different file in the tree for
a diff, it must reauthenticate to ssh, which in all reality, takes a
two or more seconds longer than the pserver method.
You could try http://www.lysator.liu.se/fsh/.
--
Ed Avis [EMAIL
Jim.Hyslop writes:
this can get cumbersome, because IIRC you must remove all revisions
from a branch before you can remove the symbolic branch tag
Nope. Some might consider this a bug, but CVS is perfectly willing to
let you remove (or move) a branch tag at any time. Of course, it then
Matthew Herrmann writes:
I upgraded to 1.11.9 but this didn't solve the problem.
Sorry, I knew there were a number of fixes to that code and I was hoping
that they would fix the problem. Now that I think about it a bit more,
however, I don't think it's fixable. I don't think there's any way
Jim.Hyslop writes:
If that's the case, then why was the revision number ever exposed in the
first place? Is it a legacy of RCS or SCCS - do they not support symbolic
tags?
I cannot say for sure, but presumably it's exposed in CVS because it was
exposed in RCS, which was the model (as well as
this is a 1Ghz P3 w/512mb. No SMB being used for local passwd auth.
Can't believe this is TOO slow.
- Original Message -
From: Patton, Matthew E., CTR, OSD-PAE [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, December 02, 2003 10:05 AM
Subject: RE: Auth using PAM
On Tue, 2 Dec 2003, Greg A. Woods wrote:
[ On Wednesday, December 3, 2003 at 02:12:59 (+1100), Craig O'Shannessy wrote: ]
Subject: Problems with uncommitted working directories, from home and work.
I never had this problem before, I've been using ssh and vi for years,
but now I'm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Craig O'Shannessy [EMAIL PROTECTED] writes:
The next best solution is to religiously use rsync to update your home
machine's working directories and then always rsync your @home edits
back to your work machine for any CVS operations which
Hi Larry,
But the problem of missing tags should only come up when a file initially
doesn't exist, and then does. The reverse cannot happen because the dead
revision should still be tagged, shouldn't it(?) if the file is removed via
cvs rm. The only exception would be a faulty tagging process
43 matches
Mail list logo
