Up-to-date check failed for 'module'

[David Berry]

Dear Gurus,


I am having trouble understanding
the up-to-date check. We are converting
our software group from using RCS to 
CVS. I am modifying our scrips to use
the CVS commands. During my testing
of CVS, I have run across the up-to-date
check failed several times. My tests involve
simply checking out a set of software, making
NO changes and checking it back in. I have
noticed the following:

I have versions 201.4, 201.5 and 201.6 .
There is NO difference in the code in 
any of these versions, except for the 
revision string $Id:$
When I check out 201.4 and try to check
it back in on top of 201.6, I get the
following:
cvs commit: Up-to-date check failed for `alnmo.c'
cvs [commit aborted]: correct above errors first!
cvs commit: Up-to-date check failed for `alnmo.h'
cvs [commit aborted]: correct above errors first!
cvs commit: Up-to-date check failed for `alnmo.nsd'
cvs [commit aborted]: correct above errors first!
cvs commit: Up-to-date check failed for `makefile'
cvs [commit aborted]: correct above errors first!
cvs commit: Up-to-date check failed for `ChangeLog'
cvs [commit aborted]: correct above errors first!
  -
Since the code is identical, how do I correct
the above errors??

When I do a cvs diff, I get the following:

cato:/users/721/berry/src/scripts/esproc/alnmo% cvs diff
cvs diff: Diffing .
Index: ChangeLog
===
RCS file: /cm/cvs/esproc/alnmo/ChangeLog,v
retrieving revision 201.4
diff -r201.4 ChangeLog
1c1
< $Id: ChangeLog,v 201.4 2001/06/21 14:57:36 berry Exp $
---
> $Id: ChangeLog,v 202.7 2001/06/21 14:57:36 berry Exp $
Index: alnmo.c
===
RCS file: /cm/cvs/esproc/alnmo/alnmo.c,v
retrieving revision 201.4
diff -r201.4 alnmo.c
3c3
<  $Id: alnmo.c,v 201.4 2001/06/21 14:58:16 berry Exp $
---
>  $Id: alnmo.c,v 202.7 2001/06/21 14:58:16 berry Exp $
Index: alnmo.h
===
RCS file: /cm/cvs/esproc/alnmo/alnmo.h,v
retrieving revision 201.4
diff -r201.4 alnmo.h
1c1
< static char h_rcs_ver[] = "$Revision: 201.4 $";
---
> static char h_rcs_ver[] = "$Revision: 202.7 $";
Index: alnmo.nsd
===
RCS file: /cm/cvs/esproc/alnmo/alnmo.nsd,v
retrieving revision 201.4
diff -r201.4 alnmo.nsd
196,197c196,197
<domain =  $ENUMERATE "$Revision: 201.4 $"
<default = "$Revision: 201.4 $"
---
>domain =  $ENUMERATE "$Revision: 202.7 $"
>default = "$Revision: 202.7 $"
Index: makefile
===
RCS file: /cm/cvs/esproc/alnmo/makefile,v
retrieving revision 201.4
diff -r201.4 makefile
2c2
< # $Id: makefile,v 201.4 2001/06/21 14:58:22 berry Exp $
---
> # $Id: makefile,v 202.7 2001/06/21 14:58:22 berry Exp $
cato:/users/721/berry/src/scripts/esproc/alnmo%


Regards,
David Berry

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

RE: The use of CVS Branches???

[Thornley, David]

> -Original Message-
> From: Patrice Martin - GRE [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 21, 2001 8:22 AM
> To: [EMAIL PROTECTED]
> Subject: The use of CVS Branches???
> 
> 
> Hello,
> 
> I use CVS V1.10, and i am in confusion with the CVS branches.
> 
If that's 1.10, with no .7 or .8 after it, you should upgrade.
1.10 is not Y2K-compliant, and if you use date specifications
anywhere you're going to have problems.

> First, what is the basic difference between "cvs commit" and "cvs
> import"?
> 
The intention is that "cvs commit" is for changes you make, and
"cvs import" for tracking other people's code.  The main difference
is that "cvs import" is much more sweeping than "cvs commit", and
models what you'd want to do when getting the latest source release.

> I think that my problem came, because i track my source evolutions by
> always doing an "cvs import" from the head directory of my project.

In doing that, you are not making the best use of CVS.  You could do
about the same thing with a collection of dated tarballs.

I'm not going to tell you you're doing the wrong thing here, but
you do need to understand that this is not how CVS was intended to
work.  You can pound in a nail with a wrench, but it's not easy
to pound in a nail and tighten a nut at the same time with the same
wrench.

> I have made this choice, because there is often lot of modifications
> made at the same time in that project.
> So in intent to not do "cvs commit", "cvs add", "cvs remove", 
> and so on
> each time, from file to file, or directory to directory, i do an "cvs
> import" one for all, starting at the head directory of the 
> project, once
> i want to do a version.
> It's work well like this until last month.
> 
Hmmm. Massive changes seem to work with "cvs commit" here, and
everywhere else I've heard of.  What do you do for small changes?
By treating your code as if it were vendor code, you at least
make it harder to use CVS like a real SCM system.

> But recently, i want to make branches for tracking parallel 
> development
> of the project, because one part of the project go in maintenance, and
> the other part stay in development with evolutions and new
> functionalities.
> 
Right.  This is not usually a problem.  However, since you're
doing the wrong thing, you're having problems.  What you need
to do to make this work smoothly is to do your changes on
checked-out copies and commit your work, not make your changes
on external copies and import it.  This will leave you
doing what most of us do, and what CVS was designed for, and
then it's much easier to help you.

So, make sure all the "vendor" changes are merged to head.  Cut
a branch for the maintenance version, using a branch tag, a
start tag, and a merged-up-to tag.  Check out workspaces to do
your development in, and commit from there.

When you commit a bug fix to the maintenance release, merge the
changes from the merged-up-to tag to head, and move the merged-up-to
tag.

> But by doing like this, i cant merge the modifications made in that
> branch, because
> the cvs (in fact rcs) revision number doesn't match the cvs revision
> number of the trunk.
> And then the diff, update and merge commands doesn't work very well...
> 
If you're sweating the revision numbers, you're doing something wrong.
IIRC, multiple vendor branches (and that's what you're proposing)
have always been awkward.

> So now i am completely confused with the used of branches with CVS.
> 
> May i have some explanations and help to understand what's happen, and
> then try to fix my problem,
> and then used correctly CVS branches, for tracking parallel 
> development.
> 
Correct use of CVS branches depends on correct use of CVS.  Once
you are using CVS as it was designed, you will find it far easier
to use CVS features.

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

RE: Future CVS Development

[Thornley, David]

> -Original Message-
> From: Kostur, Andre [mailto:[EMAIL PROTECTED]]
> > -Original Message-
> > From: Noel L Yap [mailto:[EMAIL PROTECTED]]
> > 
> > CVS only requires files to be mergable.  This has a different 
> > meaning from
> > requiring files to be non-binary.
> > 
> > One thing that may be done is to add a hook for pluggable 
> > diffing/merging
> > engines.
> 
As discussed before, this would require at least an extension to the
RCS file format.

The trick is the CVS definition of mergeable, which doesn't just
mean that some sort of diff and patch will produce a file, but
rather that merging two sets of changes is likely to make sense.
That's the usual case with the source code it was originally
designed on, although it's not universal (I remember one case in
which two different changes added elements to a hard-coded array
in different places, and both incremented the array size constant
by one).  If the file format doesn't preserve some sort of locality
(so that a fairly small change affects only one part of a file)
then it has to be treated special.  This is why I'm not hopeful
about Xdelta.  (Another essential part is presenting the merged
file, with conflicts, to the user to resolve, usually by some method
that keeps both changes.)

> Now, pluggable engines would be truly cool!  I know that one 
> large argument
> against CVS here (my office) was that it doesn't do 
> "intelligent" things
> with proprietary format non-mergable files (like MSWord 
> documents), where
> other source control systems can do (the counterexample was always
> Clearcase).  But if you could plug in a diff/patch tool for 
> *.doc files,
> (and perhaps a different diff/patch tool for *.ppt, another 
> for *.xls) that
> would make these files mergable, and thus behave sensibly in CVS! :)
> 
Because of the above, you'd probably need one diff/patch tool for
every file format, and you'd need to keep the diff/patch tools
steadily updated for changes in file formats (MS Word file formats
come to mind as changeable).  This is in contrast to the diff/patch
standard in CVS, which applies to a large number of different sorts
of files, and can remain unchanged.  I'm not sure producing diff/patch
tools for arbitrary file formats is reasonable to expect out of an
open source project.

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

RE: Future CVS Development

[Thornley, David]

> -Original Message-
> From: Noel L Yap [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 19, 2001 11:03 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: RE: Future CVS Development
> 
> 
> 
> >As I just mentioned in another somewhat related thread anyone and
> >everyone is "free" to design and implement a replacement for CVS.  If
> >such a thing actually succeeds in replacing CVS then that's an
> >achievment to be applauded.  In the mean time CVS does a fair job at
> >what it's been designed to do and there seems to be no shortage of
> >people who have requirements that it can specifically fill.
> 
> I haven't looked at it yet, but this may be it:
> http://www.netcraft.com.au/geoffrey/katie/
> 
> Noel
> 
See also
http://subversion.tigris.org/index.html
which I've been keeping an eye on now and then.  It is explicitly 
intended as a CVS replacement, and includes Karl Fogel among the
developers.  It appears to have been making steady progress,
if slower than scheduled.



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

RE: (no subject)

[Thornley, David]

> -Original Message-
> From: Randall Weigers [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 18, 2001 9:52 AM
> To: '[EMAIL PROTECTED]'
> Subject: (no subject)
> 
> 
> 
> 
>   Can you review the attached list and tell me how CVS 
> fairs in regard
> to the characteristics we are looking for in a source 
> management system??
> Thanks !
> 
><> 
> 
>
No, I cannot review the attached list - or, to be more precise,
I will not.  I do not open attachments from people I do not
know, and I don't know you.  Please review the information
at

http://www.cvshome.org/

and, if you have further questions, please post them as plain
text.

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

RE: Maintaining branches...

[Thornley, David]

> -Original Message-
> From: Ralph Mack [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 13, 2001 10:52 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Maintaining branches...
> 
> 
> [Quoth I... :-)]
> > 0. select a reference version and a from and to version
> > 1. make a diff from the reference version to the "from" version
> > 2. make a diff from the reference version to the "to" version
> > 3. merge the diffs (preferably with optional user input), and
> > 4. apply the result to the "to" version.
> 
> As I lay in bed thinking about all this, it suddenly occurred to me 
> that, since CVS is always using the root as its reference version, 
> CVS (and its ancestor RCS) can get away with not recalculating any 
> diffs at all during an update but merely selecting from among the 
> diffs calculated during prior commits. This is a significant time 
> savings. A commit becomes the only operation that actually 
> calculates a diff as a side-effect.
> 
CVS does not always use the root as its reference version.  The
restriction is not that CVS does not permit merging, but that
it does not itself have an automatic way of keeping track of
what has been merged where.  The user can keep track of this
information with a tag, or externally, or can just merge the last
change (which is usually what you want to do anyway).

A commit is not the only operation to create a diff; the "cvs diff"
command will normally also do so (although that diff is not
kept by CVS; if you want to keep it as a diff you can save it yourself).
For example, "cvs diff -r 1.10.2.6 -r 1.12.6.3 foo.C" will create
a diff between the version of foo.C in two different branches.
(If you like, "cvs update -r 1.23.2.3 foo.C; cvs update -j 1.10.2.6
-j 1.12.6.3 foo.C" will attempt to apply the difference between
1.10.2.6 and 1.12.6.3 to 1.23.2.3, which is usually not a useful thing
to do.)

> Is this true? If so, it seriously restricts the kind of merge 
> behavior that CVS can support, but I can see why it was done. 
> Lots of other things about CVS that seemed a little odd also 
> suddenly become comprehensible.
> 
It restricts the kind of merge behavior that can be done without
further ado and record-keeping.  It does not restrict the ability
to arbitrarily merge if the user is willing to keep track of things
in some way.  We use a tag to show what has been merged already.

> How hard is it to extract three different revisions of the same 
> file to a temp area outside of the normal checkout tree using 
> CVS?

If I were going to do that, I'd do three separate "cvs update -r ..."
commands, moving each to the appropriate directory after the update.
Again, it is not something that CVS automatically does with a simple
command out of the box.

 (I'm contemplating what a seperate graphical merge utility 
> layered on CVS might need to do.)

If I were to use this approach in order to use a different merge I
would write a script to do it.  There is certainly no reason why it
can't be done, but for most purposes CVS's merging is quite adequate.


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

Re: Nasty assertion error when trying to checkout a tagged revision

[David Zaroski]

On Tue, 12 Jun 2001, Bruce Pennypacker wrote:

BP>Larry Jones wrote:
BP>
BP>>Bruce Pennypacker writes:
BP>>>
BP>>> > cvs checkout -r RA0irbl011631
BP>>> corp/search/c++/applications/summarizerService/SummarizerService.cpp
BP>>> > cvs: lock.c:177: lock_name: Assertion `(__extension__
BP>>[...]
BP>>> > (CVSroot_directory == 0' failed.
BP>>
BP>>That generally indicates that one or more of the directories in that
BP>>path are really symbolic links, which confuses the CVS lock code.
BP>
BP>Bingo.  We just moved the repository for maintainence reasons and added a
BP>symlink to keep the old path valid.  I guess we'll either have to move the
BP>repository back or set up a different root for it...

Or just use the full path with the global '-d' flag.

.Dave



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

Importing with a revision number?

[David Berry]

Is it possible to import a new
source set with a revision number,
such as 201.1? In my trials as a
new CVS user, the source set took
revision 1.1.1.1 upon importation.
I would like to import new programs 
a user defined revision number.


Regards,
David Berry
[EMAIL PROTECTED]

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

RE: Use of CVS on large scales

[Thornley, David]

> -Original Message-
> From: Bob Bowen [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 11, 2001 8:20 PM
> To: John Minnihan
> Cc: [EMAIL PROTECTED]
> Subject: Re: Use of CVS on large scales
> 
> 
> John Minnihan wrote:
> > Do you have specific experience with CVS 'breaking down and 
> becoming unusable'?
> > If so, please share that experience here so others may 
> learn from it.
> 
> I think there are two obvious areas where CVS doesn't scale well:
> 
> 1) Working with branches - the interface is just too primitive and
> clumsy for large numbers of users to do the right thing. It's not too
> bad if you have just a few branches and a couple of people 
> that know how
> to use them, but even then it's tedious. 
> 
Yeah, but in a large project you can afford some administrative
work to automate this.  Given a consistent naming scheme, it's not
difficult to write a script that will do the merge.

Basically, it has to determine what branch the current file is checked
out on, what it was last merged to (maintaining, say, a BRANCH_1
and BRANCH_1_MERGED tag), and doing the merge and keeping the merge
tag up-to-date.

Figure out what you're going to do with branches and how you're
going to do it, and write scripts to do it.  I use Perl.

> I would say the biggest deficiency is having to keep track of what's
> already been merged, but it's also a pain to figure out what 
> has changed
> on a branch and making sure you've merged what's necessary without
> always having the entire repository checked out (time consuming in
> itself for large projects).
> 
I have several copies of a fairly large repository checked out right
now, and I keep them handy.  Disk space is fairly cheap nowadays, and
it's usually better to keep the repository checked out than to check
it out only when you need it.

As far as determining what has changed, this can be done with a little
process discipline.  Whenever creating a branch, create the branch tag
(BRANCH_1), a merge tag to keep track of what has been merged to wherever
you merge to (BRANCH_1_MERGED), and a start tag to record where the branch
started (BRANCH_1_START).

> 2) Building a unified development process on top of CVS; e.g. 
> enforcing
> conventions and policies which are inevitable as the size of 
> the project
> grows. The hooks again are too primitive and each script 
> shouldn't have
> to be called for every directory involved. The interfaces to the hooks
> are all different and not enough information is available, e.g. what
> branch is this on? I'm continually frustrated by the holes in the
> support for the checkin templates in the client/server methods as well
> as the lack of interactivity with the callout scripts.
>
This is a problem; it is not necessarily possible for the verify
scripts to enforce policies.  How necessary it is to enforce the
policies (as opposed to, say, detecting violations and talking to the
violator) is itself a matter of policy, and some projects may need
to enforce them.  In this case, I'd suggest some sort of approach where
checkin or tag approval is granted separately, in another sort of
system, and a simply verifymsg (for checkin) script checks that.
It's not ideal, but I don't have experience with anything that is.
That's what we're planning to do.
 
The standard answer is that CVS is intended for source code management,
not development process control.  It wouldn't be suited for development
process control, as all such tools I've seen tend to assume a certain
process, and CVS is intended as a generally useful tool.  The hooks
could indeed be improved, and there's been discussion of that in the past.
> 
> My sense is that CVS is adequate for small, fairly 
> independent projects
> (even large numbers of small, independent projects ala 
> sourceforge), but
> it's certainly not industrial strength. Unfortunately, nothing else is
> either, so most commercial efforts end up growing their own.
> 
It seems to work well on larger projects, although I have no experience
with it on really large projects.  Do you mean that most efforts grow
their own process on top of an existing SCM system like CVS?  It seems
to me that growing a SCM system is not a trivial thing, and that it
would be best to start with something like CVS and grow from there.

There are other available systems.  ClearCase is frequently mentioned
as superior to CVS in many ways.  The Subversion project at www.tigris.org
is designed as an improved CVS.  It will feature better branch and merge
handling, although I don't know anything offhand about its hooks.


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

Re: Lots of modules need merging

[David Zaroski]

On Mon, 4 Jun 2001, Steve Smale wrote:

SS>Bit of a nightmare one here...

A bit of an understatement.

SS>We therefore have project, project1, project2, project3, and project4, all
SS>of which are later stages of the same project, and all of which have a few
SS>weeks worth of version information in them.
SS>
SS>The thing i want to try to do is to pull them all into one module,

Can be done.

SS>'project', with using tags to mark each position. If the version
SS>information in each module can bekept, that will be ideal, but i guess if
SS>not we /could/ live without it...

Keeping the version info is not going to happen if he was creating new modules
of the same project all along. :-(

SS>Does anyone have any idea how i could go about doing this?

Here's one scenario:

cvs co -P project1
cd project1
cvs import -d -I\! -ICVS -m "[whatever]" project [vendortag] [release tag]
cd ..

Then do your merge, which a hint may or may not be given from the above
import.  Repeat the above process until all extraneous project[2-4] are
imported and merged into the single project.

.Dave



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

Re: Wrong timezone.

[David Fuller]

It sounds like you have to change the timezone your server is using. 
That would be dependent on what OS you are using, which you didn't
mention the server configuration.

-- David F.

Karsten Aarrebo Pedersen wrote:
> 
> I have installed cvs on a windows NT machine and have the following problem:
> 
> Each time I commit a file, the timestamp is 2 hours off (also shown in
> wincvs). I guess it is because I am in the CET (GMT+1) and it is currently
> daylight saving (+1 hour) for the summer.
> 
> The clock on my NT machine is set correctly to the current timezone and
> daylight saving.
> 
> Since I am not going to do multi timezone development, I would like cvs to
> use the time Windows are using.
> 
> Does anybody have a solution to this problem?
> 
> regards
> Karsten.
>

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

Re: WinCVS with ssh password

[David Fuller]

This page on SourceForge has links to a couple good documents and
information to help you set up the client to work with SSH.  Mostly, you
can just avoid setting up the public key so you have to use a password.

http://sourceforge.net/docman/?group_id=1

-- David F.

Daniel Stolz wrote:
> 
> I'm trying to get CVS over/through ssh to work from a Win2K box to a
> repository on a RedHat Linux box.
> 
> I can log in from Win2K using ssh.  However, I'm having trouble getting the
> CVS part to work.
> 
> The primary issue is that I'd like to force users to enter the password when
> performing CVS actions (or doing anything else with ssh).  From what I can
> tell, all of the instructions imply that you set up public key
> authentication so that a password is not required.  I think I'd like to
> avoid that.
> 
> When using WinCVS, I get the following response:
> ---
> cvs export: warning: unrecognized response `remoteuser@remotehost's
> password:
> ' from cvs server
> ---
> A DOS box appears, but it does not seem to wait for me to type in the
> password.  It just fails and hangs, waiting for me to dismiss the DOS box.
> 
> When using commandline CVS, I get the following response:
> ---
> ' from cvs serverng: unrecognized response `remoteuser@remotehost's
> password:
> Access denied
> ---
> It's repeated 4 times.  It hangs until I hit Ctrl-C.
> 
> Two questions.
> 1. Does anyone know how to get it to let me type the password.
> 
> 2. (OffListTopic) Am I being unreasonable?  Is public key authentication OK?
> (I know.  It's an ssh question)
>

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

Re: Browsing the repository

[David Fuller]

Except that 'cvs co -c' only lists out the available modules, not what
is in those modules.  I agree with Andre, this would be a "good" feature
to add to CVS.  Except that the logistics of it are problematic.

-- David F.

Karl-Heinz Marbaise wrote:
> 
> Hi there,
> 
> Did you ever think about the modules file and using "cvs co -c" ?
>

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

Re: tag dates

[David Zaroski]

On Thu, 24 May 2001, Matthew Riechers wrote:

MR>
MR>"McCann, Brian" wrote:
MR>>
MR>> Hi,
MR>>
MR>> Our build script tags our builds nightly, when I do a cvs log  on a file I
MR>> get output showing all the tags,  but there is no date associated with the
MR>> tag.
MR>>
MR>> Is there away to get the dates the tag was put on the source code?
MR>
MR>This won't tell you the date you made the tag, but the log tells you the
MR>tags associated w/ each revision number. Just look at that revision
MR>entry for its date. In the future you can put the date/time in the tag
MR>itself, or just log the tag name (build number) and date in a seperate
MR>file , and use that as a reference.

Another option would be to write a script to display the tags, revision and
date of that revision for a particular file. The benefit of doing so is that
there are no performance penalties that can occur if you log every tag
operation via taginfo. For instance (a snip of output from my script):

cvs_1_10_8 : 1.1.1.24 date: 2000/03/17 19:32:47  author: dez
cvs_1_11_1 : 1.1.1.26 date: 2001/04/27 04:36:10  author: dez

.Dave



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

[Newbie question] When LOGIN fails

[David A. Cobb]

Today I was working with a repository at the other end of an SSH tunnel.

My CVS LOGIN was rejected: "server denied access to ${CVSROOT}"

However, while experimenting with Xemacs/PCL-CVS I requested to STATUS,
and then to UPDATE my directories.  Both functions apparently worked.

Does this indicate that the login only applies to a comit?
Is this by design, or is it a big security hole?

David A. Cobb, Software Engineer, Public Access Advocate, All around nice guy.
Get my PGP key at
:<http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=superbiskit>
Fingerprint=0x{6E3E_DB8C_2E8C_4248_62B2_FE29_08EE_CF0A_3629_E954}
"By God's Grace I am a Christian man, by my actions a great sinner."
--The Way of a Pilgrim, R. M. French [tr.]
<---.!.!.!.!.!.!.>


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

[Newbie Question] Flag records

[David A. Cobb]

I understand from reading here that CVS includes all of RCS, in one way or 
another.

Are lines such as " $ID$  something " and "$DATE$ something" features of RCS?
And how do they get there in the first place?

David A. Cobb, Software Engineer, Public Access Advocate, All around nice guy.
Get my PGP key at
:<http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=superbiskit>
Fingerprint=0x{6E3E_DB8C_2E8C_4248_62B2_FE29_08EE_CF0A_3629_E954}
"By God's Grace I am a Christian man, by my actions a great sinner."
--The Way of a Pilgrim, R. M. French [tr.]
<---.!.!.!.!.!.!.>


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

Re: login problems - problem details given clearly

[David Zaroski]

On Tue, 29 May 2001, Larry Jones wrote:

LJ>David Zaroski writes:
LJ>>
LJ>> Create file 'cvspserver' in '/etc/xinetd.d' (containing the following):
LJ>>
LJ>> service cvspserver
LJ>> {
LJ>> flags   = REUSE NAMEINARGS
LJ>> socket_type = stream
LJ>> protocol= tcp
LJ>> wait= no
LJ>> user= root
LJ>> server  = /usr/bin/cvs
LJ>> server_args = cvs -f --allow-root=/home/bhavani/cvsroot pserver
LJ>> }
LJ>
LJ>You should also have:
LJ>
LJ> passenv = PATH
LJ>
LJ>to avoid problems with $HOME being set inappropriately.

Correct, you may also have to use xinetd's 'env' option as well, depending
on how you start the xinetd process. I left those options out of the above
description since they apply more to xinetd than CVS, but they can be
very important depending on the circumstances. ;-)

.Dave



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

RE: Linux security issues as they pertain to CVS

[Thornley, David]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 25, 2001 7:48 PM
> To: Mark
> Cc: CVS Mailing List
> Subject: Re: Linux security issues as they pertain to CVS
> 
> 
> The problem is that pserver cannot be made secure.  Literally cannot.
> It runs on a raw, insecure TCP circuit and is subject to all kinds of
> man-in-the-middle attacks, connection hijacking, spoofing, etc.
> 
Any problems with running pserver over an encrypted channel?  It seems to
met that would be just as secure as ssh access (and, of course, just as
unsafe - the biggest potential security problems being the guys on both
ends of the channel).
 

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

Re: login problems - problem details given clearly

[David Zaroski]

On Tue, 29 May 2001, Bhavaniprasad Polimetla wrote:

BP>My xinetd.conf file is as follows.
BP>
BP>#
BP># Simple configuration file for xinetd
BP>#
BP># Some defaults, and include /etc/xinetd.d/
BP>
BP>defaults
BP>{
BP>instances   = 60
BP>log_type= SYSLOG authpriv
BP>log_on_success  = HOST PID
BP>log_on_failure  = HOST RECORD
BP>}
BP>

Remove the following from 'xinetd.conf':

BP>2401 stream tcp nowait root /usr/bin/cvs cvs -f
BP>--allow-root=/home/bhavani/cvsroot pserver

Create file 'cvspserver' in '/etc/xinetd.d' (containing the following):

service cvspserver
{
flags   = REUSE NAMEINARGS
socket_type = stream
protocol= tcp
wait= no
user= root
server  = /usr/bin/cvs
server_args = cvs -f --allow-root=/home/bhavani/cvsroot pserver
}

Also make sure that port 2401 is setup properly in /etc/services.


.Dave



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

Re: Have u got CVS on SUN SOLARIS 2.8?

[David Hoover]

> Have u got CVS on SUN SOLARIS 2.8? 
http://www.cvshome.org/dev/codeunix.html
Sun's done a good job of making sure that newer revs of Solaris can run
older binaries. The Solaris 5.6 binary should work just fine. Even the
Solaris 5.5.1 binary should be fine.

In the unlikely case that encounter problems, you can grab the source
code from that same URL and compile your own binary under 5.8.

--
David Hoover


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

RE: Information about multiple checkouts

[Thornley, David]

> -Original Message-
> From: Bhavaniprasad Polimetla
> [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 24, 2001 7:01 AM
> To: CVS
> Subject: Information about multiple checkouts
> 
> 
> Dear Sir,
> 
> I have the following situation.
> 
> User a checked out file abc.java
> When user b try to check out, it need to tell that user a already
> checked out that file.
> How can I implement it in CVS?
> 
First, exactly what do you mean by checkout?  In some systems, it gives
you a copy of the file and a lock, so that you are the only one
allowed to work on it.  In CVS, it gives you a copy of the files
and allows CVS to manage them (by means of metadata in a CVS
directory).  The assumption in CVS is that everybody who works
on a project will have their own local copy of everything that
concerns them.

The standard way to implement something like lockin in CVS is to
"cvs watch on" and ask developers to use "cvs edit" to unlock files
before changing them.  This is advisory only, and there is no way
to enforce locking, but if your developers will deliberately
bypass your procedures you've got a much worse problem than any
version control system can solve.  In practice, advisory locks
work just as well as hard locks.
 

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

Re: Chaning CVSRoot in wincvs

[David Fuller]

You should delete the old modules you had checked out.  They are
probably what is getting in your way.  Each module remembers where it
came from, so when you change the config in wincvs it will still look to
the modules you already have to figure out where they came from.

-- David F.

Sudarshan wrote:
> 
> hi
> 
> I have wincvs1.2 installed as clients, working with linux cvs server.
> 
> For the test purpose my first CVSROOT was at /projects/testproject
> and i had set the same in wincvs and it was working fine with .cvspass
> file holding the root correctly for /projects/testproject
> 
> But now the work is started and the new CVSROOT is in /projects/project1
> 
> i am not able to set this as cvsroot in wincvs , it is taking the old
> cvsroot as the one and i am now unable to checkout the modules in the
> newcvsroot even i tried
> giving the cvsroot in the command line options as
> 
> :pserver:sudhi@ganga:/projects/project1 but the .cvspass files has the
> entry for
> only /projects/testproj.
> 
> Pls help me in solving this issue.
> Even i have tried reinstalling the wincvs twice and reconfigured for the
> new cvsroot but without any success.
> 
> Pls clarify the same
> 
> Thanks
> 
> Sudarshan
> 
> ___
> 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: Setting up CVS repositery in unix

[David Fuller]

RTFM!!  http://cvshome.org/docs/manual/cvs.html

-- David F.

Anuruddha Abhayasinghe wrote:
> 
> Hi
> 
> I want to set up a repositery in a unix machine and
> windows NT clients should be able to access it.Please
> can u let me know how to do this
> 
>Thanx
> Himanu
> 
> =
> visit http://www.rasikadayarathna.net
> 
> __
> Do You Yahoo!?
> Yahoo! Auctions - buy the things you want at great prices
> http://auctions.yahoo.com/
> 
> ___
> 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: Deleting modules

[David Fuller]

rm -rf modulename

-- David F.

"Roberts, Iwan(LIT)" wrote:
> 
> Hi,
> 
> This question must have been asked a hundred times - How do you delete an
> entire module from the repository?
> 
> Thanks,
> 
> I.
> 
> Iwan Roberts
> Project Manager
> 
> Liberty Information Technology  Direct Line: ++44 (0) 28 9044 5552
> Clarendon House   Fax:   ++44 (0) 28 9044 5511
> 9-21 Adelaide StreetSwitchboard:   ++44 (0) 28 9044 5500
> Belfast, Northern Ireland BT2 8DJ  Email:
> [EMAIL PROTECTED]
> 
> Disclaimer: The contents of this e-mail and attached files in no way reflect
> any policies of Liberty Information Technology Ltd.
> 
> ___
> 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: jCVS problem

[David Fuller]

This sounds like a jCVS problem.  You should get ahold of them.

http://www.jcvs.org/

-- David F.

Iqbal Shaikh wrote:
> 
> Hi All,
> 
> We are having a problem with jCVS Client,
> we have got sun servers on which jcvs client is installed.
> 
> >From WinNT workstations we connect to the Sun Serevrs
> through an X-Emulation software called Exceeds.
> 
> When a connection is made to the Sun Servers and start the
> jcvs client on the WinNT nodes ,
> jCVS is very very slow and it also disables the other exceed windows,
> 
> Any ideas - please reply
> 
> regds
> iqbal
> 
> ___
> 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: Crazy idea - replace RCS backend with ClearCase...!!!

[David D. Hagood]

While this is a twisted idea (I mean that in a good way ;) there may be 
some other good that could come from such an effort:

Consider: if you seperate the interface from the actual storage, you 
could in theory enable:

1) storing the data as a compressed image. This would help reduce the 
growth rate of the repository.
2) Storing the data in some form of database. This could allow the 
addition of atomic commits and other A.C.I.D. operations.
3) Making the backend of CVS into a kernel module (ducks and dons 
flamesuit laughing maniacally ^).




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

RE: CVS bookmarker or addressbook

[Thornley, David]

> -Original Message-
> From: Christian Robottom Reis [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 22, 2001 2:08 PM
> To: [EMAIL PROTECTED]
> Subject: CVS bookmarker or addressbook
> 
> 
> 
> Us people that delve in the maze of Free Software 
> repositories have one
> task that's dull -- keeping track of the CVSROOT strings for 
> every project
> we want to pull.
> 
> Is there something shell-oriented that provides something like that? A
> means to add and use root strings by a key or an index? This would be
> quite useful, and I'm sure I'm not the only one looking. :-)
> 
I don't understand the problem.  Each project has a CVSROOT string that is a
pain to type, but usually you need to type it precisely twice.  After that,
the information is in the CVS/Root file for the project, and the password
is in ~/.cvspass.

For example, I've got a local checkout of CVS here somewhere.  If I have
that as a working directory, CVS will assume I mean to use the cvshome
repository, and everything works just fine.
 

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

Re: Problem with watches & cvsroot

[David Fuller]

Did you re-checkout the module after switching to the rsh method?  That
could be why it is still trying to look at f:\

-- David F.

> Giuseppe Milicia wrote:
> 
> Hi guys,
> 
> following the suggestion got here now I run cvs in client/server mode
> using rsh authentication.
> 
> Nevertheless I still have problems, this is the log of a commit:
> 
> 
> CVSROOT: :server:xxx.xxx.xxx:/quantum/development/cvsroot (.rhosts
> authentication)
> 
> TCL is available, shell is enabled : help (select and press enter)
> 
> cvs commit -m "Added warning in the javadocs" Material.java (in
> directory D:\Sources\1.0\java_src\com\test\bl\objects\)
> 
> Checking in test.java;
> 
> f:\cvsroot/1.0/java_src/com/test/bl/objects/test.java,v <-- test.java
> 
> new revision: 1.18; previous revision: 1.17
> 
> done
> 
> Could Not Create Child Process (error 3)
> 
> The could not create process refers to the mail command. And the F:
> drive is the network mounted drive I previousl used instead of the
> client/server configuration.
> 
> Any idea of what is going wrong? why does it use the F: drive now??
> 
> -- Giuseppe

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

Re: Help....

[David Fuller]

No real magic to it.  Just pick up the repository folder and move it to
a new location.

-- David F.

>We currently have a CVS server for our software guys. I need to move 
>the CVS server to a new Machine and we don’t
>have the expertise in house to perform this, so we want to out source it.. any ideas 
>or help…

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

Re: Cvs connection : UNKNWN HOST

[David Fuller]

I haven't had that problem with IP addresses for several versions of
WinCVS, since 1.0.2 I think.  Try updating to the 1.2 version of WinCVS
which works much better than any of the older versions.

-- David F.

Werner Müller wrote:
> 
> Okay,
> it might work if you use servername instead of IP number of Server.
> also you can try to activated LMHosts (System->network->WINS-address)
> 
> It seems Cvs needs to have names instead of ip-numbers (don't  ask me why). I
> don't know how the  underlying function  gethostbyName() works, but it seems it
> works  right with LMHosts activated
> 
> Strange anyway 
> 
> Werner
> 
> Werner Müller schrieb:
> 
> > Hi all,
> >
> > I'd like to connect from my CVS Client on NT to CVS Server on Linux, but i
> > always get the message "Unknown host" .
> > Both computer are in the LAN.
> > And i even can connect from another NT Client to the CVS Server.
> > Does anyone know where this problem comes from? Or which configuration files i
> > may have to check.
> > Anyway i'm wondering that i couldn't find this error in the docs ..
> >
> > cu
> > werner
> >

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

Re: Red v white icons in WinCVS

[David Fuller]

Have you been playing with your system clock lately?  If the timestamp
on the file is different from the one specified in the CVS folder then
WinCVS will think the file has been touched.  Try running 'cvs status'
to get WinCVS to figure out that they haven't changed.

-- David F.

Larry Meadors wrote:
> 
> OK, it's Friday afternoon, and I'm stumped.
> 
> Why are some icons red and some white in wincvs? The docs say "After modifying a 
>file, the files ICON in the WinCvs file window will turn red and the Status will 
>change to Mod. File as shown in the following example where applmain.c was modified:".
> 
> But I just checked everything out, nothing has changed. Yet, every one of mine is 
>red?
> 
> Hmm
> 
> Larry
> 
> ___
> 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 connection : UNKNWN HOST

[David Fuller]

That sounds like a networking issue to me.  Perhaps something with your
nameserver?

-- David F.

Werner Müller wrote:
> 
> Hi all,
> 
> I'd like to connect from my CVS Client on NT to CVS Server on Linux, but i
> always get the message "Unknown host" .
> Both computer are in the LAN.
> And i even can connect from another NT Client to the CVS Server.
> Does anyone know where this problem comes from? Or which configuration files i
> may have to check.
> Anyway i'm wondering that i couldn't find this error in the docs ..
> 
> cu
> werner
> 
> ___
> 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: using different user

[Thornley, David]

> -Original Message-
> From: richard degetel [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 18, 2001 3:20 AM
> To: [EMAIL PROTECTED]
> Subject: using different user
> 
> 
>  When I want to be log in a different user, I change the 
> preference setting
>  but when I do cvs login, cvs did as I wanted to log in whith 
> the old user
>  
CVS will, apparently, want to log in as whoever is specified in the root
value (i.e., ":pserver:[EMAIL PROTECTED]:/home/ces/repository").  If this
is specified with the -d option, it will use that value.  If not, it will
use CVS/Root if that exists, otherwise the CVSROOT environment variable.
Presumably you're in a directory checked out under username A, and you're
using username B, and so it looks at the CVS/Root file.

(We're having a somewhat similar issue.  We often, in the course of reviews,
want to use "cvs diff" in people's code.  This requires logging in again,
which is not a problem since everybody's got the same CVS password, for
simplicity.)
 

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

Re: Limiting cvs log

[David Zaroski]

On Tue, 15 May 2001, Richard Wesley wrote:

RW>I am attempting to figure out what changes I made to a set of files I
RW>got from a vendor last year.  cvs log spits out waaay too much
RW>useless info including files I didn't modify, no matter what settings
RW>I use.
RW>
RW>All I really want is something like:
RW>
RW>RCS file
RW>date version comment
RW>date version comment
RW>
RW>RCS file 2
RW>...
RW>
RW>but ONLY for the changes I made in a date range on the main branch.

What options did you feed 'cvs log'? If you didn't use any options check
out 'cvs -H log'. With those options you can get pretty picky as to what
is output from 'cvs log'. :-)

.Dave



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

Re: Assertion failed at setting branch tag using rtag

[David Zaroski]

On Thu, 17 May 2001, chaessig wrote:

c>Oups, I forgot to give the CVS version : I'm using the last version
c>(1.11.1p1).

c>> Actually, I got this assertion error twice.
c>>
c>> I reproduce this behavior using the :local: connection protocol.
c>>
c>> But when I do a checkout of the IHM module, put the same tag in this
c>> module using the tag command, and then update -r R1, it works !
c>> The commands run are :
c>> cvs -d  checkout IHM
c>> cd IHM
c>> cvs -d  tag -b R1
c>> cvs -d  update -r R1

I have seen this as well, but only when accessing a  that is
actually a symlink. For instance if you have:

/cvsroot -> /foo/cvs

If you do the above commands like this (for the above):

cvs -d /foo/cvs rtag -b R1 IHM

You will not get the assertion error. I believe this error will occur for
all the direct accesses (rtag, rlog, rannotate) of a repository *if* the
 is a symlink.

BTW, don't confuse 'tag' and 'rtag', 'rtag' operates directly on the repository
where as 'tag' works on your working dir and the repository.

.Dave




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

Re: hash.c :312 Assert filed Key != NULL

[David Fuller]

Well, you may want to consider simply renaming the rcs file to the
correct case.  Anyone who has that file checked out will have to
re-check out the file.

-- David F.

Amit Tewari wrote:
> 
> Hi,
> 
> We are getting this error
> 
> "hash.c :312 Assert failed Key != NULL"
> 
> When we are trying to re-add a file in right "Case"
> which was removed from CVS using "cvs remove" from NT
> which off course is not case sensitive.
> 
> The story is that file was initially added on the
> branch and never got added to the trunck but CVS
> automatically adds version 1.1 on the trunk anyway
> then file was removed "using cvs remove " because it
> was in the wrong "case" ( say file.txt) when we tired
> to readd it using "cvs add" with the right "Case" (
> say File.txt) we started getting following error
> 
> Assertion failed: *rcsnode == NULL,
> 
> We found out from the list that there is bug and hence
> renamed the file to "file.txt.old' and then tried to
> add it again but then we got
> 
> "hash.c :312 Assert failed Key != NULL"
> 
> What we want to do is to add the file in the right
> "case" ( File.txt )
> 
> I will greatly appreciate any help in this regard
> 
> Thanks
> Amit
> 
> __

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

RE: problem with LF <--> CRLF trasnlation

[Thornley, David]

> -Original Message-
> From: Mike Castle [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 15, 2001 9:28 PM
> To: info-cvs
> Subject: Re: problem with LF <--> CRLF trasnlation
> 
> 
> 
> But.
> 
> The rule of thumb is:  only check out onto the machine that 
> your are going
> to make changes on.
> 
> If you are going to compile/edit on a Windows box, use a 
> windows client.
> If you are going to compile/edit on a Unix box, use a Unix client.
> If you are going to compile/edit on a Mac, use a Mac client.
> 
Yesterday, I had a problem in that a coworker had a file in cygwin
that had been edited with something that left it with Windows
line endings, and CVS checked it into the main repository (on a Unix
machine) with Windows line endings.  Should I encourage developers
to continue to use CVS on Cygwin, or should I push them to use WinCVS?
Cygwin acted as if it were in the twilight zone between Windows and
Unix in this case.

> 

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

RE: Newby : moving/renaming files loses version information?

[Thornley, David]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 16, 2001 7:43 AM
> To: Hondros, Constantine
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: Newby : moving/renaming files loses version information?
> 
> 
> "Hondros, Constantine" <[EMAIL PROTECTED]> writes:
> 
> > Does moving / renaming a file in CVS necessarily mean that 
> the "new" file
> > ends up at version 1.1?
> 
> If you do it in the way you describe (which is the only way that I
> know about to do it without directly frobbing the repository) then
> yes.
> 
Since it is generally advised to ignore the version numbers and keep
track of things with tags, this is not usually a problem.  It is possible
to do "cvs commit -r ", but that usually doesn't buy
you anything.

> > I followed the instructions at the (excellent) red-bean CVS 
> tutorial thusly
> > :
> > 
> > floss$ mv oldname newname
> > floss$ cvs remove oldname
> > floss$ cvs add newname
> > floss$ cvs ci -m "renamed oldname to newname" oldname newname
> > 
> > and found that the "newname" file started at version 1.1. 
> > 
> > Is this situation avoidable?
> 
> Yes, if you're willing to move things around in the repository itself,
> and if you're willing for the resulting file to show up in the old
> location when you do a checkout based on an old date or tag. 
> Just do this:
> 
> 1) in the repository, do "cp oldname,v newname,v"
> 2) in a work directory, do "rm oldname; cvs remove oldname; 
> cvs commit"
> 3) Still in the work directory, do "cvs update" to get a 
> working copy of newname.
> 
This keeps the history, but has the potential to check the file out
twice.  If I do that, I always remove all the tags from newname
(cvs stat -v to get the tags, cvs tag -d TAGNAME newname to get rid
of the tags).  If the file is on active branches, it's better to
get rid of version tags only, and kill oldname on all branches by
"cvs update -r  oldname; rm oldname; cvs rm oldname;
cvs commit", branch by branch.

Every way of renaming a file in CVS has awkwardnesses or inconveniences.
If you move the file in the repository, you lose the ability to check
out the file with the right name for previous tags or dates.  If you copy
the file in the repository, you can wind up getting two copies.  If you
remove and readd without touching the repository, you've split the history
and made it difficult to get diffs between versions.
 

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

RE: Secure Connections

[Thornley, David]

> -Original Message-
> From: Echlin, Michael [mailto:[EMAIL PROTECTED]]
> Sent: Monday, May 14, 2001 3:38 PM
> To: 'Santimore, Matt'
> Cc: '[EMAIL PROTECTED]'
> Subject: RE: Secure Connections
> 
> 
> Hi,
> 
> As someone else has already said pserver will use the unix 
> login passwords
> of anyone who is a user on that unix server. Set-up all of 
> your wincvs users
> as users on your server and put them in the right group to 
> see your cvs
> repository.

I felt very uncomfortable in doing that, since it leaves the unix
passwords hanging out in the open, albeit in encrypted form.  I
simply assigned a standard CVS password and told people to use that.
I have no qualms about leaving CVS insecure, because I figure CVS
is insecure, and there are other ways to limit access.

BTW, I've run into an inconvenience.  In the process of checking over
one another's code, we're constantly using CVS in other people's
directories (primarily "cvs diff").  Is there a way to avoid having
to "cvs login" in every new account accessed, since the trees in
different people's accounts have different CVS/Roots now?

(For example, I've logged in for my own account, CVS/Root file
being :pserver:me@cvs:/..., and now I have to review Roland's code.
Roland's code is in his directory, CVS/Root file :pserver:Roland@cvs:/...,
and before I do a "cvs diff -u" I have to "cvs login".  Fortunately I
set up all the passwords the same, so it's no big deal.)
 

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

Re: WinCvs & different editors

[David Fuller]

I think WinCVS has its own mailing list.  But just to answer your
question, when you double-click on a file WinCVS will run whatever the
default program is associated with that file type in MS Windows.  You
would have to look into file associations in Windows to change the
editors for a file type.

-- David F.

Justin Wall wrote:
> 
> Is there a way to specify an editor based on a file type in winCVS?
> 
> Thanks,
> 
> Justin
> 
> ___
> 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: Administering questions

[Thornley, David]

> -Original Message-
> From: Anita Chacko [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, May 13, 2001 8:57 PM
> To: [EMAIL PROTECTED]
> Subject: Administering questions
> 
> 1.Is it a good practice to allow every developer in
> the project to add/delete files/directories in the
> repository according to their requirements?Or should
> this be restricted such that only the cvs admin will
> be able to do this?Any good reasons for whatever the
> answer is?Should these additions/deletions be
> documented?

Here, every developer can add or delete files as needed.
The neat thing about SCM is that, assuming that the
developers don't have direct access to the repository
and don't use some of the less-known features of "cvs admin",
everything is recoverable.  If you have an incompetent or
malicious developer, that person can cause a good deal of
temporary confusion, but (after that person is fired), it
will be possible to clean up.

The one problem I've had with having developers add files
is that they often add them only to the branch that they're
on, when they should also be on head.  I've largely solved
that by providing a add-file script for people to use.

> 2.Same question as above with regard to check
> ins.Should the cvs admin handle all the check ins?Any
> reasons for this?

I see no good reasons for this in normal use.  There might
be reasons to have one person do the checkins in special
cases.  Perhaps the repository and development staff are
large, and there have been problems with updating during
large checkins and not getting a consistent view of the
repository.  (Even so, it might be better to have reserved
times for checkins in that case, rather than having an
administrator handle it.)  I'd suggest letting developers
do their own checkins.

> 3.Is there any purpose/use in documenting all check
> ins?
> 
Um, documenting how?  They're already logged in the history
file (if you've turned that on), and will be listed in the
output of "cvs log" for a file.  We require checkin comments
that link the file to the PR, and a list of changed files in
the PR itself (we use Gnats for bug tracking), and forbid people
to check in without a valid PR.  This has been enough to handle
all desired inquiries for us.

> I can't say how much I would appreciate any help as I
> am really at a loss and have no senior persons to whom
> I may put such questions.Infact before me,there was no
> version control system used at all in this project. 
> 
Look on the bright side.  Anything you do will make things a
lot better.  You will almost certainly make mistakes, but
SCM run by somebody who does a pretty good job is much better
than no SCM at all.  CVS runs well in the absence of much
administration (the state of affairs here before I took it over).


 

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

RE: query tag

[Thornley, David]

> -Original Message-
> From: Zanabria, Moises [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 11, 2001 3:25 PM
> To: '[EMAIL PROTECTED]'
> Subject: query tag
> 
> 
> Hi there:
> Is possible to know who person created a tag??
> How can I do this?
> 
If you have history enabled and usable (I can't access the file here because
it's become too large) you could use "cvs history" with the proper options.
It apparently won't tell you what the tag name was, but it'll apparently
tell you who and when and on what file, and you may be able to figure it out
from that.
 

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

three questions on modules

[David Hoover]

I've got three questions on modules:

1) I see the -s option to assign a status. This sounds fairly neat, and
I was surprised to see that almost nobody seems to use it. Is there any
particular reason not to?

2) If I _do_ use the -s option, is there any way to include spaces in
the status? I've played with it a little, and it appears that I'd have
to write_status_info_like_this.

3) Is there any way to make a module inclue branch information? We're
going to have two big branches that people will be working on, and I'd
love to be able to make a module named 'foo-version10' and one named
'foo-version20' that would be equivilient to 'cvs checkout -r version10
foo' and 'cvs checkout -r version20 foo'. It's not the end of the world
if I have to make people throw the -r on, but if it was possible to
specify a branch in a module definition, it'd make life a little easier.
(In the same vein, it'd be handy to do that with non-branch tags also,
i.e. 'cvs checkout -r version20-build foo' which is a tag on the
version20 branch that'll get moved every time CM does an official build)

None of these are show-stoppers, but they could make life a little
easier.

Thanks for any input

--
David Hoover
Cadence Design Systems

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

RE: problem with cvs log -d

[Thornley, David]

 

  -Original Message-From: Gabrio Verratti 
  [mailto:[EMAIL PROTECTED]]Sent: Friday, May 11, 2001 1:52 
  PMTo: [EMAIL PROTECTED]Subject: problem with cvs log 
  -d
  one of 
  my colleagues modified a set of files three days ago.  I need to back out 
  what he did and I cannot contact him to find out which files he 
  touched.
   
  I wanted 
  to use the date range feature of cvs log to see all commits from the developer 
  in question on the given date, but I cannot seem to be able to get the date 
  format correct.  I have tried many different formats, of which, I've 
  listed only a couple:
   
  cvs 
  -v
  Concurrent Versions System (CVS) 1.9 (client)
   
  I 
  believe that this is your problem right here.  1.9 was not Y2K-compliant, 
  and I've seen problems with
  trying to specify post-1999 dates in that version 
  before.  I think you may have to upgrade, preferably to 
  the
  latest 1.11.1 version.
   
  This 
  is probably not the best time to upgrade, but I don't know if you can make 
  that work on 1.9 at all,
  and 
  you really should have upgraded before January 1, 2000.  (I think that 
  may be why there's a lot of
  1.10.7s out there - that was the latest version 
  available in November 1999 or so when I got the job of
  upgrading.)
   
   
  
  
  
  


  

  
Brokat Technologies
150 Almaden Blvd.
San Jose, CA 95113
(800) 
876-4900
www.brokat.com
   

Re: check in a big file

[David Fuller]

Couple questions: 
1) how big is the versioned file?  
2) why are you versioning such a big file?  I would consider that a
'BAD' idea.

-- David F.

> Rafael Luque Leiva wrote:
> 
> Many thanks all for your previous help.
> 
> Now I have another problem. I'm trying to add a big size file (~80MB)
> in my cvs server running over SuSE 7. Before commit, the output of a
> "free -m" in the server is:
> 
> root@quintin:/home/ltr > free -m
>  total   used   free sharedbuffers
> cached
> Mem:   127 16111  0
> 5  3
> -/+ buffers/cache:  7120
> Swap:  128  2125
> 
> However when I commit the file using WinCVS1.2, after minutes, my
> client aborts with:
> 
> cvs [server aborted]: out of memory; can not reallocate 82700697 bytes
> 
> How many free memory I would need to commit this file? Some way to
> work round this problem with big files?
> 
> Thanks in advance,
> 
> Rafa,

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

RE: Suspicious email message intercepted

[Thornley, David]

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 10, 2001 12:57 AM
To: Donald Sharp
Cc: Laine Stump; [EMAIL PROTECTED]
Subject: Re: Suspicious email message intercepted


[ On Wednesday, May 9, 2001 at 14:18:51 (-0400), Donald Sharp wrote: ]
>> Subject: Re: Suspicious email message intercepted
>>
>> Actually it's a fairly good thing to send out the warning email
>> to a list.  People might thus avoid getting the virus.

Alternatively, somebody might read through all the warning messages and
be sufficiently numbed when he or she reaches the actual virus to do
something stupid.  Or take so long wading through them that the person
misses something important in the mail.  We had about half a dozen
warnings sent to the list for one malicious email.  If three of them had
hit the list, we'd have enough warning messages to fill a screen.

>Actually it IS NOT!  NEVER EVER send such stupid lame warnings to a
>public list, either by hand or automatically  EVER

I would except Maarten de Boer's warning, which was interesting and
useful, showing people what the virus was.  I also trust his judgment in
only sending it to the list once.

To be more precise, the automated messages to the list said, essentially,
"this might be malicious", which is something I'd already figured out.
Maarten de Boer said, in one message, that it was malicious and why.
I learned something from his message.

>If some people want to read the list with vulnerable mail readers then
>that's their risk to take.  But the idiots running broken scanners must
>be taught to never EVER send bounces to list, no matter what the reason!

Actually, that's the risk their companies may be taking.  I was shifted
over to Outlook by corporate policy yesterday (so I'm in a mean mood),
and I figure that top management is responsible for that risk.  (Not that
there's any great danger from me using Outlook as opposed to some of the
other people)

FWIW, my wife's employer wasn't bothered at all by Homepage, and didn't
spam mailing lists either.  Her mail software currently strips out .vbs 
attachments on incoming mail.  I'd suggest that as a policy for those who 
don't want to take the risk of incoming Virus Bombardment System payloads.
If you miss something useful that somebody else posts to the lists, then
send a private email asking for a zipped version, or included in the message
body, or something like that.

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

RE: I have a question

[Thornley, David]

 

  -Original Message-From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]]Sent: Thursday, May 10, 2001 8:09 
  AMTo: [EMAIL PROTECTED]Subject: I have a 
  question
  Hello ,
   I am baesy .
  I work in Korea. 
  I want to control binary file . 
  My OS is Linux . 
   
  First I make tar-file. 
  I cvs import tar-file . 
  But original file and imported file differ . 
  Size of orginal file is 16691200.
  Size of imported file is 16691124. 
  And I can't execute tar xvf imported file . 
  
  Why does it do ?
  How can I cvs import binary file (*.tar file ) . 
  
  please help me . 
  I will be waiting for your answer. 
  
   
  [Thornley, David] What do you mean "imported 
  file"?  Do you mean the file in the
  repository, or one checked out later?  The 
  file in the repository is not supposed
  to 
  be used directly.
   
  And, 
  for that matter, why are you controlling a tarball?  Why not skip the 
  whole
  tar 
  process and just import the individual files?  Importing a tarball makes 
  no sense
  whatsoever.  Importing is a way 
  to allow your own development on somebody else's
  code 
  while keeping track of their changes and merging them in.  If they're in 
  a tarball,
  they're not going to merge, so you're getting 
  nothing out of it.  If you must keep a
  tarball around, use "cvs add -kb" or something like 
  that.
   
   
   

how to remove revision from tree

[David Escala]

hi,

can i remove a commit or two i don't like from the repository? how?

thanks

david


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

Questions on the vss3cvs script

[Diedrich, David]

Hi,

I'm in  the process of converting some sourcesafe files to CVS using
your vss2cvs perl script and have q couple  of questions on its use. 

How does the perl script use cvs.exe and ss.exe; I did'nt see a place in the
script on where the pointer to these executables where used so I'm wondering
if I'm missing something.

I've installed the cygwin Unix utility package on my PC and I'm working in
the cygwin Unix shell. The command line use of vss2cvs script goes as
follows:   perl vss2cvs option option option . . . 

According to the script the options work like this

perl vss2cvs workdir ssroot cvsroot ssproj cvsbranch ssuserpass

I'm assuming that this command line inputs are my root directories so are my
doing this right if I enter the options like follows:

perl vss2cvs  /cygdrive/c/sscvwork /cygdrive/c/test
/cygdrive/g/CVSTEST projectname optional optional.

 Is this correct. The reason I'm asking is the script comes back with need
cvsroot location so I'm inputting wrong but I'm not sure what's wrong


Thanks


Dave Diedrich
Design Component Engineer
Intel Corporation
Networks Processor Operations
Phone: 978-568-6982



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

RE: Suspicious email message intercepted

[Thornley, David]

What happens if someone wants to post a vbs script that works with
cvs?

doanld

Fortunately, that's at least less likely.  Most of us deal with CVS on Unix
boxes of some sort, and Virus-writers' Benefactor System doesn't run on
those.
Of course, we have had automated complaints about Perl, and I would imagine
that lots of us use Perl.  Still, some people have to deal with CVS on NT
boxes, and I suppose they may use such tools.

It wouldn't be so bad if (by my count) six different automated checkers
hadn't posted to the list, and if we couldn't expect the same six to
do so again the next time somebody uses Outlook absent-mindedly.

Could we filter out the incoming messages so that they would have to be
from somebody on the list, rejecting messages from people like
MAILER-DAEMON?

On Wed, May 09, 2001 at 10:26:32AM -0700, Stephen Rasku wrote:
> Richard Wesley wrote:
> 
> >
> >One wonders which causes more damage - lame virii from socially 
> inept 
> >teenagers or endless warnings from well-meaning servers...
> >
> 
> Exactly.  Would it be possible to configure the list to drop .vbs 
> submissions so we don't have this problem?
> 

___

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

Release of cvsstat

[David Sitsky]

G'day,

Cvsstat is a simple perl script which analyses the history of a CVS
repository, and collects statistics, such as how the number of lines
of code and number of files in a CVS module evolve over time.

Cvsstat can also interface with gnuplot to produce a figure (in png,
jpg, gif, postscript or other gnuplot-supported formats) of the data.

Its possible to specify selected filesets using a collection of
include/exclude regular expressions.  Its also possible to optionally
specify start and end dates in which to collect statistics.

Anyway, check out http://cvsstat.sourceforge.net if you are interested
to see how your CVS project evolved in a graphical way!  There is an
example graph there showing the evolution of the open-source jboss
EJB container project.

Cheers,
David

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

Re: "Triggers" & links to defect tracking systems

[David H. Thornley]

"Mark D. Baushke" wrote:
> 
> >
> > Hi,
> > Is there any facility in CVS to add hooks for customized actions?
> > For instance, requiring a Bug Number when you check in a file,
> > verifying that bugnum against your defect tracking system, etc.
> 
> It is possible to do some integration of Bug Number and a defect
> tracking system by having the rcsinfo template provide a form for you
> to fill in the bug number and haveing the verifyinfo trigger used to
> validate that the log message provided by the user has a valid bug
> number or other information.
> 
What I was thinking of doing was using the loginfo hook to
check the checkin comment to see that there is a PR number,
and then verify that this is a valid PR with checkin approval
(we've been having problems with some people checking in stuff
without permission, and I'd rather put at least one tooth into
the "don't do that" message).

Does anybody foresee a problem with that?

> I am not aware of any othters, but it might be desirable for the
> commitinfo step to be able to prompt the user for information such as
> the bug number or other information in order to better catch typos in
> a bug number earlier. While this is possible if you are using a local
> repository or the rsh/ssh transport, I don't know of any way to do it
> with the :pserver: method of interaction.
> 
And here I'm just getting the shop on pserver.  Fortunately,
I'm not looking for interactivity, just compliance.

-- 
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: Writing a macro in CVS

[David Fuller]

You might want to be looking into 'cvs checkout -r tagname modulename'
which will check out all the files in module 'modulename' that have tag
'tagname'.

-- David F.

Anette Van Aswegen wrote:
> 
> Hello
> 
> I am writing a script in Tcl/Tk to retrieve all the files in CVS which have
> the same tag. The user enters the tag in a textbox and
> then all the files with the specified tag must be listed. How do I go about
> to search through the CVS repository and to get the tag part of the file
> information?
> 
> I am fairly a novice to Tcl/Tk and would appreciate your help greatly.
> 
> Kind Regards
> 
> Anette van Aswegen
> 
> Rubico (Pty) Ltd
> Reception:  +27 (11) 808 1000
> Fax:  +27 (11) 808 1101
> [EMAIL PROTECTED]
> www.Rubico.com
> 
> The Business Component Company
> 
> ___
> 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: GUI for CVS in Linux

[David Fuller]

http://www.cvsgui.org/

Amit Bakhru wrote:
> 
> Sir,
> I want to implement CVS in my company.
> Is there any GUI for CVS in Linux.
> If yes, please send me the link where can i download it.
> 
> With Regards,
> 
> Amit Bakhru
> 
> ___
> 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: P on Update?

[David H. Thornley]

Chris Edgington wrote:
> 
> The CVS client documentation talks about the meaning of various letters returned
> on an update command, like U for update, M for merge, C for conflict, but the
> doc does not mention what the P stands for. Looking at the source, it looks like
> it stands for patch. What does it mean to the end user - is there any different
> between the effects of an Update or Marge versus a Patch?
> 
Actually, M doesn't stand for Merged in the update output, but
rather Modified.  If you change a file and update the directory,
it will show up as M even if there are no changes in the repository.

There is no difference to the user between U and P, it being
internal to CVS.  Having different letters here is (I think)
something of a wart.  AFAIK, U means the whole file was sent
from the repository, and P means a patch was sent.

-- 
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: Undo a branch

[David Fuller]

See the CVS manual on Tagging.
http://cvshome.org/docs/manual/cvs_4.html#SEC51

Example from the manual of deleting tag "rel-0-4" from file "tc":
cvs rtag -d rel-0-4 tc

-- David F.

Jerry Nairn wrote:
> 
> Hi,
> A colleague is writing a branch creation script which will make a branch
> point tag name and a branch name based on the purpose of the branch
> following a set of conventions, tag the branch point, and create the branch.
> It all looks pretty good, but he asked me today about the best way to "undo"
> a branch if the user decides he made a mistake. My answer was that this
> shouldn't be something you do so carelessly that you would frequently want
> to undo it, but that answer didn't satisfy him.
> So my question is (are) what is the best way to undo a branch in an
> automated way? What are the issues to look out for?
> And actually, one of the things we discussed was the possibility of moving
> the branch rather than removing it, if the branch point was on the wrong
> revision.
> So commands which might be used are:
> cvs tag -d ...
> cvs admin -o ...
> cvs tag -F -b ...
> cvs admin -Nnewname:oldname ...
> We hope that this will only need to be done in situations where no new
> revisions have been checked in on a branch, but any ideas about how to deal
> with problems arising from such revisions are welcome.
> Any ideas or advice will be greatly appreciated.
> Thanks,
> Jerry
> 
> ___
> 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: importing vendor branches

[David L. Martin]

> > Fergus Henderson writes:
> > > 
> > > The reason that this broke things is that `cvs checkout'
> > > was checking out inconsistent versions of different files.
> > > After the import, some files -- those which we had not modified -- now
> > > had revision 1.1.2 on the vendor branch, and only 1.1 on the main branch,
> > > and `cvs update -A' retrieved revision 1.1.2, i.e. the vendor branch.
> > > But for other files, their version on the main branch was 1.2, and on
> > > the branch it was 1.1.2', and `cvs update -A' retrieved revision 1.2,
> > > i.e. the main branch.  So `cvs update -A' was checking out some files
> > > from the main branch (based on gc_4_1 with our modifications)
> > > and some from the vendor branch (gc_6_0_alpha6).
> > > Trying to mix incompatible versions naturally broke things.
> > > 

When a new RCS file is created as a result of cvs import, the
RCS archive's default branch is 1.1.1.  When/If the first local modification
is committed, the default branch becomes blank (= the trunk).  See the
output of cvs log in the "Branch:" field.  The tip of the default branch
appears to be what is regarded by CVS as the revision to retrive
in an update -A.

To make update -A retrieve the trunk revision (1.1) for locally
unmodified files which have been imported, you could use cvs admin -b
on all files created by the import to force the default branch to be empty
(i.e. the trunk).

To avoid this mess, you might consider moving your development
from the trunk to a branch.  You'd be guaranteed that a vendor
import would not affect the contents of your development branch,
until you decide to merge the vendor branch deltas yourself using
standard merge procedures.

Hope this helps,
David Martin



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

Re: CVS and Scripting

[David Fuller]

Many of the administrative files allow you to call scripts when an event
occurs.  CVS doesn't have specific support for any scripting language,
as long as the script is executable by the server.

-- David F.

[EMAIL PROTECTED] wrote:
> 
> Hi all,
> 
> Does CVS provide any hooks for specific scripting languages?
> 
> Thanks,
> 
> Adam
> 
> ___
> 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 & web processes

[Marshall, David]

I'm not certain that this document solves the problem you're expressing, but
it's still pretty good stuff.

http://philip.greenspun.com/wtr/cvs.html

-Original Message-
From: Justin Wall [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 03, 2001 2:45 PM
To: [EMAIL PROTECTED]
Subject: CVS & web processes



I'm going to use CVS to maintain a web application.  Because the
code has 
to go through an application server, I would like to have the team share 
the same working directory.  Does anyone see a problem with this?  We are 
testing right now, and it looks like if someone has checked out the module, 
and then someone else tries to commit, it tries to login with the user 
account of the person who originally checked out the file.

Thanks,

Justin


___
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

CVS directory structure

[David CM Weber]

I'm working on a design document on our Version Control System (VCS) in
house.  I'm personally reccomending CVS (for various reasons), but alas,
the decision is not mine.

What is really the most important (IMHO) is the directory structure of
the VCS tree.  It needs to be intelligent, flexible, and well designed
because it potentially could be in use for the next 50 years.  This is
what I've come up with:

VCSROOT\Products\\

VCSROOT would be CVSROOT for CVS

Products is for software products.  There'd be a documents directory and
other things, but this just allows an abstraction of the source code
stored

 is a "Module", where a module is defined as a directory
structure with one or more of the following directories:



Zero or more sub-module directory(s) (derived from module)
Allows for the logical splitting of a module into logical pieces
Each follows this formatting (yes, I know it's a recursive
definition) 

Inc
Header files allowing other modules use of this modules
components

Bin
Binary files created by this module
Executables should be placed here after compilation

Src
Source files for software products developed in-house

Lib
Library files (lib's, dll's, and other libraries placed here)
created by this modules

Common (Derived from module)
Files common to sub-modules should be placed here
Allows for the update of these files, without copying them to
potentially dozens of sub-modules

External (Derived from module)
Files not produced internally should be placed here
I.e.: Source bought or grabbed as examples (Code Guru), should
be placed here. Similar reasoning to "Common"
It's not ours, and we really shouldn't muck w/ it
If we do modify it enough to make it "ours" it should be placed
into Src

Doc
Documents produced for this module




So, and example executable Foo (which uses the "Bar" and "Kung" static
libraries)

path:
VCSROOT/Products/Foo/

Sub Dirs:
Bar - Static Library
Kung - Static Library
Common - Files common for the sub-modules
Src - Source for the "Foo" executable
Bin - Contains the final build of "Foo" executable




Something is nagging in the back of my head that I'm not doing something
correct, or I'm forgetting soemthing.  Could you guys poke holes/ ask
questions to help me develop this further?


Thanks


Dave Weber

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

FW: Questions about your product

[David CM Weber]

Thanks,


Dave Weber
Backbone Security, Inc.
570-422-7900





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 03, 2001 10:16 AM
To: David CM Weber
Subject: RE: Questions about your product






Does it have topic and development listing link to each project folder?
[Dave Weber] Don't think so
[Wayne Johnson] If you mean by this, can you create reports that link
changes to
specific change requests and problem reports, the answer is:  With a
little
work, yes.  CVS contains features that allow scripts to be executed at
checkin
to verify update integrity.  Things like checking that specific
information like
Change request numbers, etc. are included in the change description;
Source
contains no tabs, etc.  It also has an exit that can be used to update a
change
control database.  You can add problem description information to this
database
and then add source version id's to relate.  It's all there, just has to
be
written by some ingenious soul.  Wonder why someone hasn't GNU
"productized"
this yet.

Does it have some reporting feature?
[Dave Weber] Depends on what kind of report info you want.
[Wayne Johnson]  There are commands to list all or a range of changes to
some or
all modules, listing all change descriptions.

What is the primary platform it runs on (client/server/pc)?
[Dave Weber] Just about anything you want.  Clients: Mac, Win, Linux,
and a variety of unix's.  Servers: Win, Linux, and the Unix's
[Wayne Johnson's shameless plug] And don't forget about my current port
for
OS/390 (AKA MVS).  This runs under OS/390 Unix System Services (or TSO
if you
have HFS set up).  The client is working splendid but the server is
untested as
yet.

Does it track across platforms?
[Dave Weber] Not sure what you mean by this.
[Wayne Johnson] The above mentioned scripts work on the CVS server so
that any
checkin control and reporting occurs on a single point.






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

RE: Questions about your product

[David CM Weber]

Someone correct me if I'm wrong
 
Most of this can be gathered from http://www.cvshome.org
 


-Original Message-
From: Mark Sweet [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 03, 2001 9:07 AM
To: [EMAIL PROTECTED]
Subject: Questions about your product


Does it have Multiple Version Tracking?
[Dave Weber] Yes 
 
Is it accessible by a number of programmers simultaneously?
[Dave Weber] Yes 
 
Does it control and record who checked software in and out?
[Dave Weber] Yes 
 
Does it check for changes whenever software is checked back in?
[Dave Weber] Yes 
 
Does it have topic and development listing link to each project folder?
[Dave Weber] Don't think so
 
Does it have some reporting feature? 
[Dave Weber] Depends on what kind of report info you want.
 
Does it work with MS Project 98?
[Dave Weber] Depends on what you mean by "work"  a pen and paper "works"
w/ project :)   If you mean "does it integrate into project", that would
be a No, or a "Not that I'm aware of" (Must... resist... urge... to...
start... a.. M$... flame... war...)
 
What is the primary platform it runs on (client/server/pc)?
[Dave Weber] Just about anything you want.  Clients: Mac, Win, Linux,
and a variety of unix's.  Servers: Win, Linux, and the Unix's
 
Does it track across platforms?
[Dave Weber] Not sure what you mean by this. 
 


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

Re: Sub-modules

[David Fuller]

In the modules file you can do things like:

# set up the inner most modules
level3a level3a
level3b level3b
# level2a also contains the level3 modules
level2a level2a &level3a &level3b
level2b level2b
# level1 also contains the level2 modules, which contain the level3
modules
level1 level1 &level2a &level2b

-- David F.

John Temple wrote:
> 
> I would like to setup cvs to allow me to create a Major Module with Sub
> Modules with in it.  With this my developers with have the capability to
> check out the Major Module with all of it's Sub Modules or each Sub Module
> seperately.
> 
> for example:
> Major Module (level1)
>|_Sub Module (level2a)
>||_Sub Module (level3a)
>||_Sub Module (level3b)
>|_Sub Module (level2b)
> 
> With this the developer can checkout level1 and get everything or checkout
> level2a which gives them that module and all of its Sub Modules.
> 
> Background:
>  Server: Windows NT
>CVS 1.10
>  Client: Windows NT
>WinCVS 1.2
>Local mounted Directory
> 
> John Temple
> Database Consulting Group
> UserInterface Designer
> [EMAIL PROTECTED]
> (770)557-4900 ext.227 Office
> (770)633-5033 Cell
> (770)966-4443 Pager
> 
> ___
> 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

Can't use CVS through rsh w/o a home directory?

[David Hoover]

I'm trying to use cvs through rsh here at work. Our password file is
distributed with yp, so we can log into all machines (and are
hosts.equiv'ed so you can rsh without a password), but we don't
necessarily have a home directory on every machine.

I've found that it doesn't seem to work if I don't have a home directory
on the cvs server:

karma-av2.0> hostname
karma
karma-av2.0> echo $CVSROOT
fire:/cvsroot
karma-av2.0> cvs -v
Concurrent Versions System (CVS) 1.11 (client/server)

karma-av2.0> rsh fire cvs -v
Concurrent Versions System (CVS) 1.11 (client/server)

karma-av2.0> cvs checkout sandbox
cvs [server aborted]: can't chdir(/mnt/dhoover): No such file or
directory

However, that _does_ make the directory "sandbox/CVS" with the
Repository, Root, and Entries file. The entries file contains just 'D'

If I then go into that directory, and do a cvs update, it checks out the
file from that directory, but it doesn't know about any sub dirs to
recurse into, which severely cripples its usefulness.

If I go onto 'fire', and make myself a home directory, it'll work. It
doesn't write anything to it (I've tried, and it works with root owning
the directory, and my uid not having write permission), it just seems to
insist on being able to chdir to it.

I've grepped, and found that the error message is in the history_write()
function, and skimming the code nearby, it doesn't seem to actually need
to go to my home directory at all (in fact, if the get_homedir()
function didn't return '/mnt/dhoover', I would be okay; it just wouldn't
try to chdir to there)

There's a comment above the get_homedir() function that makes it sound
like
some developer agrees with me that you shouldn't need a home directory
on the
server, unfortunately, the code seems the behave in a way that requires
it.

Does anyone have suggestions? I could make empty home directories for
everyone
in my group, but that would be a bit ugly. Same goes for local password
entries
overriding that & pointing them to something like /tmp. I suppose
another option would be to put something in fire's global login files
that changes $HOME to /tmp if the person's real home dir doesn't exist.

All those could work, but are a bit ugly. Plus, I've had occasion to
access another group's cvs repository, and I don't have the kind of
access needed to make any of those changes there.

Does anyone have any ideas, or should I pass this along to the bug-cvs
list & see if cvs can get modified to cope with the lack of a home
directory?

Thanks

--
David Hoover
Software Engineer
Cadence Design Systems
[EMAIL PROTECTED]
(408) 428-5580

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

Re: CVS /etc/inetd.conf question

[David D. Hagood]

[EMAIL PROTECTED] (Larry Jones) wrote:


> This results in $HOME not being set at all in the server's environment
> (which will cause CVS to compute it correctly) rather than being set to
> a bogus value.


  So, when the CVS server drops priv, it will correctly set the HOME 
variable to the user's home dir, or will it leave it blank?And if it is 
left blank, will the server correctly not look for the file, or will is 
look in the current working directory.

Actually, the point is largely moot, since the latest versions of CVS 
don't check for those files if running in server mode...



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

Re: Reserved checkouts.

[David H. Thornley]

Richard Sharp wrote:
> 
> Members Equity Email System
> But I do need to use reserved checkouts - I have examined the issues for and
> against and have decided on reserved checkouts. Some of our files will not
> be able to be merged as they are graphic files etc. Any ideas ?
> 
You don't need reserved checkouts in CVS, for the very simple
reason that a CVS checkout is not the same thing as a checkout
in a locking system.  In a locking system, a checkout typically
gets a local copy of the file and locks it; in CVS, a checkout
gets a local copy of the file and sets up the metadata for it.

What you want is some way of controlling who's working on the
file at any given time, and the CVS way to do that is to set
"cvs watch on" all files that you want to control, and ask
the developers to use "cvs edit" to unlock them.  This isn't
strict locking, but rather advisory.  Having worked with both,
I can testify that strict locking doesn't stop people from
working simultaneously on a file and blowing away other people's
changes, and advisory locking seems to work as well as strict.

So, add your binary files with -kb (or use cvs admin to put that
on later), make sure there is a "cvs watch on" on all of them,
and instruct your developers on the correct procedure.  Violation
of that procedure should be treated as any other act of sabotage.

(Noel Yap wrote some patches to put teeth into the watch/edit
process, and these can be found at the RCVS project at Sourceforge,
last I looked.  These patches were written against an earlier
version of CVS, so use with caution.)

-- 
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 OS Migration

[David CM Weber]

Hmm.  Worse case, I can just run dos2unix (or whatever it is) on the
offending files.  Not that big of a deal (just so long as I can recurse
through the directory tree) 

Thanks,


Dave Weber
Backbone Security, Inc.
570-422-7900





-Original Message-
From: Rob Helmer [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 02, 2001 12:32 AM
To: David CM Weber
Cc: [EMAIL PROTECTED]
Subject: Re: CVS OS Migration


Hi David,


CVS uses RCS on the backend, so you should be fine just
moving the files.

The only thing I can think of to watch out for is the end-of-line
convention difference between UNIX and DOS ( and Windows )..

Maybe someone more knowledgable than me on that subject can
comment. I usually just move UNIX -> UNIX.


Thanks,
Rob Helmer


On Tue, May 01, 2001 at 12:12:43PM -0400, David CM Weber wrote:
> I'm a developer in a small company, and I'm in the process of setting
up
> a CVS system for our code, documents, etc...
> 
> The final system that we're going to be installing the server is
> currently up in the air.  I'd like to get a jump start on the
migration
> of code into CVS (rearranging the directories, etc...) while the
> higher-ups decide which system to install the server.  
> 
> The clients (for the most part) will be running on Windows platforms.
> What I'm wondering, is can I make all of the archives, and do the
> versioning locally (on a win2k system).  Then when we decide which
> system we're putting it on (Linux/Sun/Win2k/Winnt), can I simply copy
> the files to the new system?  
> 
> Or, should I wait until the new system is decided, and then do it.
> 
> Thanks!!
> 
> 
> Dave Weber
> Backbone Security, Inc.
> 570-422-7900
> 
> 
> ___
> 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 /etc/inetd.conf question

[David D. Hagood]

> Instead of:
> 
> env = HOME=/home/cvs
> 
> it is much better is to specify:
> 
> passenv = PATH
> 
> (i.e., don't pass $HOME to the server at all).
> 

  The daemon is running as root when it starts. Then it drops priviledge 
to the user's level. Unfortunately, it still trys to look in root's home 
directory for .cvsignore, but as it is now running as a normal user, it 
cannot.

The PATH has nothing at all to do with this problem.


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

Re: modified cvs

[David Fuller]

As Greg said: "You *only* need to know which repository to use when
doing the initial checkout of a module -- after that it's all
automatic."  Once you check out a module from that point on it remembers
where it came from (file CVS/root in that folder).  CVS will use that by
default.

WinCVS can definately support multiple CVSROOT.  With WinCVS 1.2 you can
have different folders set up to remember your settings.  I have a
folder for each of the repositories I use, and WinCVS keeps track of all
that for me.

-- David F.

nidelet thomas wrote:
> 
> >
> > I think if you do your layout design correctly it'll also only be those
> > people who need to check out every project who need to even know about
> > the existance of multiple repositories.
> 
> yes but the people who need to check out every project work under windows
> and i don't think
> wincvs can support multiple CVSROOT... Of course they could change their
> CVSROOT every time they have to checkout a project or commit new things but
> it's a little bit too long to do..
> but thanks for the advice. If my changes come to make bugs in cvs i would
> use multiple repository...
> But i changed some code and I add a new admin file. authuser in which i
> define user per module
> like
> module:user1,user2 but i coudn't get the aliases work yet so i will see
> thanks
> 
> ___
> 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

CVS OS Migration

[David CM Weber]

I'm a developer in a small company, and I'm in the process of setting up
a CVS system for our code, documents, etc...

The final system that we're going to be installing the server is
currently up in the air.  I'd like to get a jump start on the migration
of code into CVS (rearranging the directories, etc...) while the
higher-ups decide which system to install the server.  

The clients (for the most part) will be running on Windows platforms.
What I'm wondering, is can I make all of the archives, and do the
versioning locally (on a win2k system).  Then when we decide which
system we're putting it on (Linux/Sun/Win2k/Winnt), can I simply copy
the files to the new system?  

Or, should I wait until the new system is decided, and then do it.

Thanks!!


Dave Weber
Backbone Security, Inc.
570-422-7900


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

Re: 'cvs add' ownership problems

[David Fuller]

If you set the group sticky bit on the top-level repository folder then
all subfolders will be created with that groupid.  This is an
oversimplification of what really happens, but it should be enough to
get you going again.

-- David F.

[EMAIL PROTECTED] wrote:
> 
> Hi all,
> 
> I just built cvs on my Linux box.  I set up a repository called 'fs'
> and set the owner to root and the group to 'fsdev'.  I have a list of
> users who belong to the 'fsdev' group who should be able to add,
> commit, etc... However, when I tried to add the first directory to
> the repository as user 'tvolkert', it made me owner of that directory
> (user 'tvolkert', group 'tvolkert').  That being the case, no other
> users could run a 'cvs checkout fs' because they had no permissions
> on that dir.  Here's the error msg.
> 
> .
> cvs checkout: failed to create lock directory for
> `/usr/local/share/cvs/fs/test'
> (/usr/local/share/cvs/fs/test/#cvs.lock): Permission denied
> 
> cvs checkout: failed to obtain dir lock in repository
> `/usr/local/share/cvs/fs/test'
> 
> cvs [checkout aborted]: read lock failed - giving up
> .
> 
> What am I missing???
> 
> Thanks in advance for your help,
> -T
> 
> ___
> 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 Problem

[David Fuller]

check your server logs.  you probably didn't have '-f' in your
inetd.conf line for cvs.

> sachin wrote:
> 
> Dear Sir,
> 
> From last three weeks i am tried to configure CVS in Red Hat 6.2
> server with Wincvs client 1.2.
> 
> I am facing same problem last three weeks.
> 
> i could not solve the proble with help of manuals and CVS news group.
> 
> the problem is as follows.
> 
> 
> 
> NEW CVSROOT: :pserver:sachin@cvs:/usr/local/cvs (password
> authentication)
> 
> cvs login
> 
> (Logging in to sachin@cvs)
> 
> cvs [login aborted]: recv() from server cvs: Connection reset by peer
> 
> *CVS exited normally with code 1*
> 
> can you help me out in this topic
> 
> 
> 
> sachin

-- 
===
David Fuller
Software Engineer
TechSight, a business unit of GDDS
phone:  (413) 494 - 7538
[EMAIL PROTECTED]
===

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

Re: CVS /etc/inetd.conf question

[David D. Hagood]

John Hsieh wrote:

> In order to configure the CVS server, modify the /etc/inetd.conf
> is necessary.
> 
> But in the RedHat 7.0 version software, there is no /etc/inetd.conf 
> 
> Where is the file of /etc/inetd.conf or similar configuration file in RedHat
> 7.0?

RH7.0 uses xinetd, which stores its configuration in 
/etc/xinetd.d/

You add files to that directory to add services: create a file 
cvspserver there and fill this in:

# default: on
#
# service cvspserver
#
service cvspserver
{
 disable = no
 id  = cvspserver
 env = HOME=/home/cvs
 socket_type = stream
 protocol= tcp
 port= 2401
 wait= no
 user= root
 log_on_failure  += USERID
 server  = /usr/bin/cvs
 server_args = -f --allow-root= pserver
}

The /home/cvs dirctory created to work around CVS bug #1, the "cannot 
access /root/.cvsignore" error: create this directory, make it owned by 
root, readable by all, and not writable by anybody, and CVS will be happy.



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

Re: SCC complient interface

[David Fuller]

There are packages available.  http://www.wincvs.org/ has a pretty good
list of available CVS client tools.  We use Igloo
(http://www.jalindi.com/igloo/) where I work and we are very happy with
it.

-- David F.

"Lenng, Helen" wrote:
> 
> Hi,
> 
> We'd like to try to integrate our SQL development tool, Cast Workbench,
> with CVS.  Cast supposedly can integrate w/ anything that
> provides an SCC complient interface on Windows (they say they
> can integrate w/ PVCS and Clearcase).
> 
> Does CVS provide an SCC complient interface on Windows?
> Thanks for any help.

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

Re: cvs lock problem

[David A Uebele]

If you encounter a ,DevelopersGuide.doc, file in the repository,
this is the working file that RCS primatives uses while
it is changing the file.
Typically, it works something like this:
cp DevelopersGuide.doc,v ,DevelopersGuide.doc,
make changes to ,DevelopersGuide.doc,
mv ,DevelopersGuide.doc, DevelopersGuide.doc,v

Check for existence of both files. Diff them, decide which version
is correct. Choosing the ,v file, you may throw away your newest change.
choosing the ,*, file you may only have a partial file depending on when
the commit proccess died.

dave

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

Re: 2 versions of working copies

[David Fuller]

This sounds like more of an issue with your build system.  Does it have
any paths you have to change?  

CVS doesn't really care if you have 1 version or 100 versions of files
in different locations on your hard disk.

-- David F.

Anita Chacko wrote:
> 
> Hi
> I have a  question.
> I have checked out some files and have modified them
> but did not commit them.I use these files to build a
> system.
> Then I checked out the same files again and am trying
> to build the system but without modifying any
> files.But the build system is not recognising the
> files I just checked out from the rep to build but is
> using the files which I modified but did not check in.
> Does this mean that I cannot have 2 versions of
> working copies though they are in different locations
> in my hard disk?
> (I don't know if this is indeed a CVS related
> question??)
> 
> Thanks,
> Anita Chacko
>

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

running triggers on client side

[David A Uebele]

A question.
Assuming a setup with NT clients and Solaris server for a CVS repository.

Now assume I want to run pre-commit trigger scripts on the client
side (polling users for additional information to be used as
part of an audit trail).

If I setup with psserver or similar setup, the trigger scripts run
on the server side.   In a pure Solaris or Pure NT environment,
I could do file sharing and allow the commit scripts to run on
client (not ideal, but doable, assuming you trust file sharing).

I suppose I could use Samba on the Solaris side and do the same, but
it makes really nervous.  Any other suggestions for how to run
client side trigger scripts?

Either that, or use a wrapper or figure some other way to poll the user prior
to commit and then pass this information as part of the commit process.


thanks
dave
-- 
Dave Uebele[EMAIL PROTECTED]360-876-4587 

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

Re: Directories checked out as root

[David Fuller]

I'm reminded of one of the options in the 'config' file,
PreservePermissions.  Do you by chance have that turned on?

-- David F.

Sean Ogle wrote:
> 
> Hello folks,
> 
> I am running cvs version 1.10.6. When I check out a module the directories
> have the user root assigned to them. This only happens when I use the CVS
> client on the same machine as the server. I am using pserver but even if I
> just point directly at the repository it still checks the files out as root.
> I think I am the only user that this happens to.
> 
> Any thoughts?
> 
> Thanks,
> 
> Sean
> 
> ___
> 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: waiting for [user]'s lock

[David D. Hagood]

Are you sure there are no ".#cvs.foo" files (as in, having a leading .)? 
They won't show on a normal ls, you have to do an ls -a to see them.


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

Re: $Name$ Keyword does not expand

[David D. Hagood]

Markus Grunwald wrote:

> Hi there !
> 
> I would like to use the $Name$ Keyword in my java source. To do this, I added 
> the line:
> 
> public final static String cvsRelease = new String("$Name$");
> 
> to my source. Then, I tagged it "prerelease-1_0". To get the substitution, I 
> executed
> 
> cvs -d  ":pserver:grunwalm@swscvs1:/usr/local/cvsroot" checkout -r 
> prerelease-1_0 UserAccount
> 
> but the line just expanded to
> 
> public final static String cvsRelease = new String("$Name:  $");
> 
> I thought, there should stand "$Name: prerelease-1_0$" ??? Other tags 
> ($id$...) work just fine.
> 
> The log says, the tag is there:
> 


Is prerelease-1_0 a branch or a leaf? If is is a branch, then it won't 
get expanded (I've complained about this behavior before in this 
discussion, look for my previous posts).


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

Re: $Name$ Keyword does not expand

[David D. Hagood]

Markus Grunwald wrote:

> Hi there !
> 
> I would like to use the $Name$ Keyword in my java source. To do this, I added 
> the line:
> 
> public final static String cvsRelease = new String("$Name$");
> 
> to my source. Then, I tagged it "prerelease-1_0". To get the substitution, I 
> executed
> 
> cvs -d  ":pserver:grunwalm@swscvs1:/usr/local/cvsroot" checkout -r 
> prerelease-1_0 UserAccount
> 
> but the line just expanded to
> 
> public final static String cvsRelease = new String("$Name:  $");
> 
> I thought, there should stand "$Name: prerelease-1_0$" ??? Other tags 
> ($id$...) work just fine.
> 

Is the ta prerelease-1_0 a branch tag or a normal tag? If it is a branch 
tag, then it won't expand. I've griped about this on this list before 
(check for my previous messages).


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

Re: Problem with e-mail notification

[David Fuller]

My understanding is that when you commit each folder is committed
individually.  So when you commit something which covers dirs, sub1 and
sub2, it actually gets run as 3 separate commits.

-- David F.

"Diego Sevilla Ruiz ([EMAIL PROTECTED])" wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi all!:
> 
> I have an e-mail notification when I do commit into a directory. I
> have in my CVSROOT/loginfo file an entry that looks like:
> 
> dir (mail )
> 
> However, now I have two subdirs of that directory, call them sub1
> and sub2. When I commit something which covers dirs, sub1 and sub2, I
> receive three messages, one for each subdirectory: dir, sub1 and sub2.
> 
> How can I avoid receiving three messages for an *unique* commit
> which covers more than a subdirectory. In other words, should I use a
> regexp which includes an "end of string" to refer only to the "dir"
> directory, something like:
> 
> dir$ (mail.. ..)
> 
> or
> 
> dir/$ (mail ...)
> 
> or should I use another file (commitinfo, notify, etc?)
> 
> Please, help me, because mail notification is received by a bunch
> of people and I would like to minimize the numbers of e-mails
> to one per commit.
> 
> Regards and thanks in advance.
> diego.
>

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

Re: CSV Server

[David Fuller]

Need more information.  What was the exact error message?  Have you
checked the server logs for clues?

-- David F.

> Alexander T wrote:
> 
> Dear All,
> 
>  I am a new comer to this. I have started using the JCSV 5.2.2
>I have also installed the CVS Server on a solaris m/c,and given the
> neccessary properties in the
>server property file. But the problem is I am not able to connect
> to the server.It gives server is not open error
> 
>when i try it in test mode.
> 
>   Please Help
> 
>  Rgds
> Alexander

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

Re: Converting from ext to pserver

[David D. Hagood]

David H. Thornley wrote:


> Is there any way I can turn off non-pserver access, or detect
> it when it happens?

What about marking the repository as not exported in your exports file?


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

Re: cvs server: failed to create lock directory for `/var/lib/cvs/foo' (/var/lib/cvs/foo/#cvs.lock): Permission denied

[David Fuller]

What are the read/write permissions on those folders/directories.  I
notice you are running pserver.  CVS actually wants to use the
permission of the user who logs in, not root.  Maybe you need to revisit
your permissions.  Perhaps changing the group to users and making them
group writable.

-- David F.

Jan wrote:
> 
> Hello,
> 
> Also on other requests I get different Permissions denied messages. The
> directories and files in /var/lib/cvs (and this directory itself) belongs to
> root.root and cvs is in my inetd.conf as
> cvspserver  stream  tcp nowait.400  root/usr/sbin/tcpd
> /usr/sbin/cvs-pserver
> So.. what could I be doing wrong?
> 
> Thanks,
> Jan.
> 
> __
> wincvs:
> cvs checkout -P foo (in directory D:\CVS)
> cvs server: Updating foo
> cvs server: failed to create lock directory for `/var/lib/cvs/foo'
> (/var/lib/cvs/foo/#cvs.lock): Permission denied
> cvs server: failed to obtain dir lock in repository `/var/lib/cvs/foo'
> cvs [server aborted]: read lock failed - giving up

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

Converting from ext to pserver

[David H. Thornley]

I am now working on a belated move from the ext access mode over
NFS to pserver.  What I would like to do, if I could, is ban
ext access altogether, or at least find out if it is happening
so that I can stop it.

Is there any way I can turn off non-pserver access, or detect
it when it happens?  (I can't remove accounts from the CVS
server at this time, meaning that it would take some time and
some good reasons and likely some money to do so.)

Is there anything else I should watch for during the conversion?

-- 
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: unreconised authorisation error

[David Fuller]

I'm quite certain that it isn't the length of the line.  I have  a
server running with 5 '--allow-root=...' statements.  Pretty long line.

My first guess would be that the client program is out of step with the
server program.  Remember, if you are going to patch the server then the
client will probably need the patch too.

-- David F.

mm rao wrote:
> 
> Any idea on the the max allowed length of this line?
> --- Larry Jones <[EMAIL PROTECTED]> wrote:
> > mm rao writes:
> > >
> > > Any thing to do with -P? What actually this is
> > for?
> >
> > I haven't a clue -- standard CVS doesn't have either
> > -L or -P so I
> > presume they have something to do with the patch you
> > applied.
> >
> > > Or any other guesses? Do I need to install
> > seperate
> > > RCS ( I am using cvs-1.11)?
> >
> > No, the RCS functionality has been built-in to CVS
> > for quite some time
> > now.  You're not getting an invalid option or
> > unknown command message,
> > so the problem appears to be that CVS simply isn't
> > seeing the "pserver"
> > at the end of the command line for some reason.  Do
> > you have an
> > unpatched version of CVS 1.11 that you could try to
> > see if the problem
> > is related to the patch or not?
> >
> > -Larry Jones
> >
> > Yep, we'd probably be dead by now if it wasn't for
> > Twinkies. -- Calvin

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

modules with tag/branch ?

[David Escala]

hi

is there a way you can define a module (in the modules file) to always
use a certain tag or branch? for instance, in the module "test" defined
as:

classes thirdpartysoft/classes
test projects/test &classes &htmlwidgets

I would like test to always contain the branch tagged "v_2_0" off
classes, but all other files must be the head revision. something like:

classes_2_0 -a -r v_2_0 thirdpartysoft/classes  # This doesn't
work
test projects/test &classes_2_0 &htmlwidgets

thanks in advance

david

PS. where can I find information on how people use cvs to solve SCM and
team work (CMM,TSP) issues?


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

Re: Rename a file

[David Fuller]

There are two ways to do this, both I believe are described in
documentation.

1) copy webfile.htm to Webfile.htm on your local machine.  In CVS add
it, commit it, and remove the old file.  You lose version history but
maintain stability of any tags you may have had.

2) Physically in the repository change the name of webfile.htm,v to
Webfile.htm,v and notify your users.  If any of them use a MS Windows
client they may need to edit the CVS/Entries file for that folder to
remove the old file name because of MS not being case sensitive.

-- David F.

FORTINI Massimiliano wrote:
> 
> Hi,
> my name is Massimiliano and I'm cvs-administrator into my company.
> I have a question. If I would rename a file under cvs control, i.e from
> webfile.htm to Webfile.htm, how could I do it?.
> 
> Tahnkx in advance
> 
> Massimiliano Fortini
> 
> 
> 
> Stai partendo per una vacanza? Scopri i vantaggi, in esclusiva online, che Omnitel 
>ha pensato per te!
> http://www.omnitel.it/190personal/roaming/home_eurocall.htm
>

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

$Name and branches

[David D. Hagood]

(I hate not being able to reply to the messages, but either I'm having 
problems getting email from the list or my filters rae eating the 
messages. Could be worse: they could be spitting out nastygrams ;^))

Greg:
I do agree with the bit about not allowing code out of control without a 
tag. In fact, that is the rule, and my team are very good about 
following it. Unfortunately, some salespeople don't follow the rules, 
they don't answer to me, and I cannot get a hunting permit for them.

I like to have my people commit to their personal branches frequently 
for two reasons:

First, sometimes you go down a blind alley, and you need to be able to 
back up, or at least see how you got there.

Second: this allows me to have the changes on a server that gets backed 
up nightly, so if one of the developer's machines flames|gets a virus 
(gotta love NT+Outlook...)|suffers a wildcard delete, the data can be 
recovered. Backing up the developer's machines is not politically 
possible...


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

can not rename ,temp.txt, to temp.txt,v: file exists

[David Penn]

Hi, all,
 
i met a problem in cvs. When I commit 
temp.txt, it abort with message:
 
cannot rename ,temp.txt, to temp.txt,v: 
file exists.
 
I have to remove temp.txt,v in the 
server and lose all my log and rebuild temp.txt file. However, the error occurs 
again after several revisions.
 
What's the problem? any simple 
solution?
 
My client is winCVS on Windows 98, and 
use local mounted NT share disk as repository. I search the newsgroups for help, 
some suggests to change to client/server mode. If I have to change my 
cvs mode, what's the simplest and seamless way?
 
Any response is highly 
appreciated.
 
Regards,
 
David Penn
 
Huawei Technologies Co., Ltd.Tel: 
+86-21-68810115-4110Email: [EMAIL PROTECTED]Web: http://www.huawei.com
 smime.p7s

Re: One file in several modules?

[David Dunbar]

[EMAIL PROTECTED] wrote:
> From: Keith Hearn <[EMAIL PROTECTED]>
> To: "Info-Cvs List (E-mail)" <[EMAIL PROTECTED]>
> Subject: One file in several modules?
> Date: Fri, 20 Apr 2001 15:01:23 -0700
> 
> The project for which I'm the release engineer has code broken into several
> CVS modules, based on functionality. This works fine, but there is one
> difficulty. Each module contains a Makefile.include file which contains
> various rule & variable definitions that are used by most of the other
> Makefiles.
> 
> We want to keep each module self-contained so you can just check it out and
> work on it without having to check out other modules as well. But I also
> want to keep the Makefile.include files in synch.
> 
> Currently, we have a separate copy in each module, and if I want to make a
> change I have to make the change in every copy (in 25+ modules). Needless to
> say, this is more work than I'd like for it to be.
> 
> Is there any way to have one file be in several modules? Or is there a
> better way to handle this issue?
> 

Your way is asking for trouble. 

Our system has ~150 modules and ~20 libraries. The CVS directory tree
looks something like this: 

cvsroot/
  CVSROOT/
  src/ 
Makefile
admin/ 
  Makefile
  Makefile.include
  dir1/ 
Makefile 
codea.c 
  ...
lib1/ 
  Makefile 
  lib11/ 
Makefile 
codeb.c 
  ... 
modules/ 
  Makefile 
  module1/ 
Makefile 
codec.c
  ... 

The Makefile at each level triggers the Makefiles in the lower levels.
The Makefile in the admin directory also copies the Makefile.include to
a location where all other files expect to find it. i.e. the other
Makefiles start with 

include /path_to/Makefile.include

This way the number of modules can grow essentially indefinitely. 

David 
-- 
David M. Dunbar <[EMAIL PROTECTED]>
Always drink upstream from the herd,
especially if you suspect mad cow disease.

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

Re: Diff between update and checkout/commit

[David H. Thornley]

Nigel Morse wrote:
> 
> So why is it called checkout? It's more of a copyout or retrieve coz it
> doesn't actually checkout anything
> 
Because in CVS the checkout is what gives you the ability to
check in?  It copies out the data and also puts the necessary
metadata in the CVS directories.

I would think that export would be a closer analog of a copyout
or retrieve.

-- 
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: $Name $ in branches

[David D. Hagood]

[EMAIL PROTECTED] (CVS-II Discussion Mailing List) wrote:


 > Huh?  Why doesn't the $Author keyword (part of $Id, BTW), work for you
 > then?
Because I often have developers working on several different "things" at
once. For example, I may be working on signal processing, and in a
seperate branch working on UI. Using the author keyword gives me no way
to seperate this, even though one branch is david_dsp and one is david_ui.

Perhaps for some of my junior programmers, who I don't load down with
more than one task, $Author$ might work.


 >
 > Or are the developers each checking out the entire project on their own
 > branch, working on some random part of it, and then plugging a
 > sub-product that may have been built from changes by many separate
 > developers into a common/shared test environment?
This is an embedded system. Much of the work is in hardware->software
integration. You have to go back to the lab and see if the hardware is
actually going to do what the documentation says it should do. Then you
fix your code to take into account what actually works.


 >
 > In either case though it would seem that your process is fatally flawed
 > (at least from a release management perspective).
You assume "releases" are king. I do on average of twenty builds a day
while trying to get the software and hardware to work together. I don't
want to pollute my tagspace with twenty tags a day per developer. I
don't want to have to do a cvs tag && cvs update && build && and load
cycle because I found that I have to wait 20 uSec after clearing ctrl4
before I can start the DMA, even though the HW guy says I don't. I want
to change the code, build that sub-module, verify my fix, commit the
change to my branch, and move on.

My project is designed as small, self-contained modules so that I can
better parallelize my development cycle.



 >
 > Still it would be of enormous benefit to force developers to create mini
 > releases of anything and *everything* that goes onto a common test 
system
No, for the reasons above.


 >
 > From a higher-level release management perspective there's NEVER any
 > excuse for letting something out of a developer's direct control
 > (i.e. into an environment where its origins and status must be
 > identifiable) unless it's been properly "released".
That's not what's happening. Please don't criticize my development
methodology without working here. The embedded software development
cycle is different from applications development. In apps development,
you change something, build and test on your system, and iterate. In
embedded development, you MUST test on the target hardware. Now, I'd
love to have a target system for each developer, but that won't happen.
Furthurmore, there is the isssue of loading the code onto the systems. I 
want to automate that, and for various reasons it would be useful for me 
to have the branch ID.

Unless you have more than two decades of embedded/realtime software
development experience, please don't lecture me about how to do it. I
welcome real, actionable, useful advice, but it seems to me that the 
tone of your posts is more condecending than helpful. Rather than 
telling me that my methodolgy is all wrong (without knowing what my 
methodology is, or why it is as it is), you could simply have said "you 
seem to be using $Name in a way that it wasn't intended".


 > resulting products can be shared.  You don't have to keep the tags
 > forever -- only so long as the released product exists in any place
 > where it needs to be identified.  The $Name keyword will work
 > *perfectly* for this since that's the way it was "designed" to work in
 > CVS.
Except that I must then do a fresh checkout to purswade CVS to update
the tags, then do a fresh build, then do a download. Then run for 30
seconds, swear, and begin again after changing one line of code.


 > As for letting the marketing types get away with such shenanigans, well,
 > "You create the circumstances you must live with."
Perhaps you work in an environment where your word is law. If so, 
congratulations. I, however, don't. So, I have to do what I can, within 
the context of the powers my position gives me, to solve what problems I 
can. Believe me, I am working on correcting this problem, but that is 
outside the scope of this discussion, so suggestions that I do so aren't 
really actionable.

I tell you what. If you are ever in Wichita, KS, and have a day to burn, 
stop by the plant. I will show you what I do, and why I do it. Then, if 
you can show me a better way, I'll not only listen, but see if I can get 
HR to make you an offer.



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

Re: Merging from one branch to another

[David Fuller]

Remember, when merging branches like this CVS has to work its way
(through the diffs) back to the branch point, and then up the new
branch.  Even though the files look the same, CVS keeps no information
stating that the versions can be directly diff'd.  You will often get
these pseudo-conflicts as a result of this process.  Sometimes I find it
simpler to do the branch merges myself (external program).

-- David F.

Chris Sherman wrote:
> 
> Isn't that just completely weird???  What went wrong?  Lines 4-8
> (in the last section) aren't even marked in the conflict, even
> though they went away.  And since there were never any commits
> to this file in Branch 1, where did the conflict come from in the
> first place???  I'm so confused...
> 
> 
> --
> Chris Sherman
> [EMAIL PROTECTED]
> JAPH / UNIX RE / STO
> 
> ___
> 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

$Name $ in branches

[David D. Hagood]

I disagree with Mr. Woods on this: adding the branch ID to a build makes 
sense in my environment: I have several developers, each working on 
their own branch of an embedded system. As needed, the load their code 
into target systems for development. Since the number of developers is 
larger than the number of target systems available to do development on, 
there needs to be some reuse of the systems. Being able to quickly 
identify that "Oh, this unit has Bruce's build, therefor I should 
contact him about this" would save a great deal of time.

Also, this would allow the software to automatically maintain unique 
setups across different development branches. Sometimes I want MY setups 
to be different from Bruce's, or I need to unit to access MY section of 
the server, rather than Bruce's. Again, if I can generate this 
automatically it saves an error prone step.

Additionally, I have to deal with marketing types who frequently come 
into the lab and stea..., er, borrow units to take to customers. 
Sometimes those units aren't as controlled as they should be. If the 
software can get the branch ID, it can correctly ID that is ISN'T a 
released version, and jump up and down and scream about it. This is the 
best solution I can come up with that management will allow (bludgeoning 
the individuals in question is not considered viable).

Actually, what I'd really rather see would be a $Branch$ or something 
that would allow me to contain that information.


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

Re: Xdelta and CVS

[David H. Thornley]

"Greg A. Woods" wrote:
> 
> [ On Thursday, April 19, 2001 at 11:16:31 (+0200), Maarten de Boer wrote: ]
> > Subject: Xdelta and CVS
> >
> > We are using CVS, for several projects, with great pleasure.
> > We now have the need to store and track revisions of large
> > binary files (audio analysis data). Because we are already
> > familiar with CVS, and use it with clients on various
> > platforms, we would like to use CVS for this data as well.
> 
> That would be a "not-very-smart" thing to do.  CVS does not in any way
> meet your requirements for that kind of data.
> 
More accurately, it meets requirements in a rather bad way, using
a lot of disk space and offering little benefit you wouldn't get
by gzipping and backing up the data regularly.

CVS exists to allow concurrent development involving incremental
changes to files.  Is this useful on the analysis data?

> > Obviously, storing all revisions entirely will not be very
> > efficient. The data is pretty straigthforward, and the
> > differences between versions could be extracted very well
> > with Xdelta. So Xdelta integration in CVS seems to be the
> > solution.
> 
> Sure, but if you do that then you'll be off using an incompatible branch
> variant of CVS that has no hope of ever being integrated back into the
> main variant of CVS that uses standard RCS files for storage.  Note also
> that you cannot change what is considered to be "the main variant of
> CVS" unless you convince the majority of CVS users to give up on RCS as
> the sole repository file format either.
> 
Um, what's so sacred about RCS file format?  I realize that file
formats are to be changed only with caution, but since the entire
functionality is internalized into CVS (as of 1.10, I believe)
there is no reason why it cannot be changed for a good purpose.

> 
> The second idea is just plain wrong in claiming that it would not change
> the CVS repository format since it would, by definition.  RCS uses
> "diff" and only "diff" for delta storage.  What it really proposes is to
> change RCS.
> 
No, what it proposes to do is to replace RCS.  I thought that the
essence of CVS was something other than its file format.

> Overall what that web page fails to note is that introduction of such a
> drastic change to the repository data structures would make any such
> repository incompatible with any normal RCS-only version of CVS, and
> indeed incompatible with RCS itself.
> 
Perhaps the web page author considered that it would be obvious
to the intended reader (i.e., somebody considering development
work on CVS).  In any case, I really don't care about compatibility
with RCS.  RCS is on my list of stuff I never want to use again,
not that far below COBOL.

> BTW, that web page also fails to give full justice to the size of the
> project.  If you're really serious about something along these lines
> you'd be INFINITELY better off if you simply started a new design for a
> versioning tool and wrote it right from scratch.
> 
I'm not all that familiar with CVS internals (not having had to
mess around with it like I did Gnats), but it seems to me that
we're talking about changing the repository format, nothing else.
If this is a really large project, then CVS is very badly
designed.

(Now, test and validation would be time-consuming.)

There is the obvious need for both-way conversion programs, but
after that I think the Xdelta version would see fairly rapid
acceptance.  (How rapid depends partly on how effective the
merging was, which is to say whether two changes in a file
can be merged to produce another useful file.  This would
obviously depend partly on the file format, and I'm not
an authority on common binary file formats.)

> 
> > I am well aware of the fact, that CVS has not been designed
> > to deal with large binary files, and that some people would
> > consider it undesirable to add such functionality. I think
> > it is worth the try though. As this is an important issue
> > for our project, I can spend some time on this.
> 
> You've obviously been blinded by your situation.  What you're proposing
> is somthing new and entirely different which may have a command-line
> like that of CVS, but which would otherwise not be CVS.  Calling it
> "CVS" would be wrong.
> 
Given a copy of CVS, and a copy of XCVS, with the ability to use
both but not examine repository format or source code, could
you necessarily tell the difference?  If properly implemented,
it seems to me that the changes could be mostly invisible.
Given that this could be a plug-compatible replacement to
everybody but the admins, why would it be new and entirely
different?

-- 
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: Passwd file

[David Fuller]

You'll have to turn off system auth for the passwd file to start working
right.  You'll also probably want to put something in the password
area.  Even a blank password has a crypted value.

-- David F.

Nigel Morse wrote:
> 
> I've set up CVS for remote repository, and I can login using a system user
> account (i.e. my own) but I want to use separate passwords and have CVS run
> as a common user so I can tighten permissions (more to prevent accidental
> deletation).
> 
> I created a $CVSROOT/CVSROOT/passwd file with just
> 
> dummy::cvs
> 
> in it (cvs is a system account), but I can login as dummy with no password -
> i just get the failed message. I can still login using my own (system)
> account (ultimately I will turn off the system auth. ability).
> 
> Do I have to do anything special to the passwd file to get it to be used?
> 
> >From what I can tell its the latest version (came with red hat linux 6.2)
> 
> Cheers
> Nigel
> 
> ___
> 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: applying astyle on commit

[David Fuller]

>From cvs help:

The commitinfo file defines programs to execute whenever cvs commit is
about to execute.  These programs are used for pre-commit checking to
verify that the modified, added and removed files are really ready to be
committed.  This could be used, for instance, to verify that the changed
files conform to to your site's standards for coding practice.

-- David F.

Maarten de Boer wrote:
> 
> Hello,
> 
> We use some strict rules on code layout, but of course
> people sometimes make mistakes. Luckily, astyle does a
> great job in layouting automatically. So I would like
> to apply astyle on all the code that is commited to the
> repository, so the code inside the repository is always
> correct. People would only have to do an update after to
> commit to get the formatted version.
> 
> So my question is: how can I do this? Doing it client
> side is not really an option, because we use different
> platforms, and besides, doing it server-side assures
> correct usage of astyle.
> 
> Kind regards,
> 
> Maarten
> 
> ___
> 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

$Name $ and branches

[David D. Hagood]

I'm a little confused by an aspect of CVS:

If I have a file that contains the $Name: $ keyword, and that file is 
checked out under a normal, non-branch tag FOO, the keyword will be 
expanded as $Name: FOO$. However, if the tag is a branch, the keyword 
won't be expanded.

Is there some logic behind this behavior? For some of what I am doing, 
I'd really like to have the $Name$ be replaced with the branch tag.


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