RE: cvs rlog -rTAG1::TAG2 doesn't handle newly added files

[Matthew Herrmann]

Hi Larry,

But the problem of missing tags should only come up when a file initially
doesn't exist, and then does. The reverse cannot happen because the dead
revision should still be tagged, shouldn't it(?) if the file is removed via
cvs rm. The only exception would be a faulty tagging process where the file
wasn't tagged with others. In that case I would say it's a faulty behaviour
coming from incorrect use. The alternative of faulty behaviour from correct
use is more serious.

The branching problem you mentioned doesn't come up for the coming up into
existence problem, because every file always starts from 1.1. Said another
way, every file has a single beginning, but multiple possible ends.

In this case, my suggestion of selecting every revision up to the end tag
makes sense, doesn't it?

People's thoughts?

-- Matthew


-Original Message-
From: Larry Jones [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 3 December 2003 7:48 AM
To: Matthew Herrmann
Cc: CVS Mailing List
Subject: Re: cvs rlog -rTAG1::TAG2 doesn't handle newly added files


Matthew Herrmann writes:
>
> I upgraded to 1.11.9 but this didn't solve the problem.

Sorry, I knew there were a number of fixes to that code and I was hoping
that they would fix the problem.  Now that I think about it a bit more,
however, I don't think it's fixable.  I don't think there's any way for
CVS to intuit, in the general case, what a missing tag should mean.  For
example, if it's the end tag that is missing and there's more than one
branch past the start tag, which branch should CVS follow?

-Larry Jones

Oh, now don't YOU start on me. -- Calvin



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

Re: Problems with uncommitted working directories, from home and work.

[Mark D. Baushke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Craig O'Shannessy <[EMAIL PROTECTED]> writes:

> > The next best solution is to religiously use rsync to update your home
> > machine's working directories and then always rsync your @home edits
> > back to your work machine for any CVS operations which you'll run by
> > logging into your work machine just as you did with 'vi'.
> > 
> 
> Considered this too, just don't know if I trust myself that much, I've 
> already lost work once this way.  Spose I'm just not that religious.
> 
> > >  I'm currently considering sshfs, but the performance won't be
> > > good.
> > 
> > Use rsync over ssh!  :-)
> > 
> 
> Wouldn't have done it any other way ;)

I suppose you could also consider the Unison File Synchronizer (see
http://www.cis.upenn.edu/~bcpierce/unison/ for details) as a way to keep
your checked out trees in a consistent state with one another.

Enjoy!
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQE/zUSz3x41pRYZE/gRAtQmAKDIob1hMY/1VDkVV3pE+DbLvr0RFQCgqjtU
G3HEB9tJssRet4rGBA2aeh4=
=yis4
-END PGP SIGNATURE-


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

Re: Problems with uncommitted working directories, from home and work.

[Craig O'Shannessy]

On Tue, 2 Dec 2003, Greg A. Woods wrote:

> [ On Wednesday, December 3, 2003 at 02:12:59 (+1100), Craig O'Shannessy wrote: ]
> > Subject: Problems with uncommitted working directories, from home and work.
> >
> > I never had this problem before, I've been using ssh and vi for years,
> > but now I'm addicted to an IDE (idea), so I've gotta find a better
> > solution.
> 
> Is "idea" an X11 application?  If so then how about X11 forwarding
> through SSH?  I.e. run it on your work machine just as you did with 'vi'.
>

I've considered this, but "idea" is a Java application (Swing), running on 
X, but there are serious performance problems running java apps over the 
net, apparently something to do with the "double buffering" Swing does to 
give snappy client performance, and hencedoesn't play very nice with 
bandwidth.  I've also tried remote desktop things like VNC, but they don't 
give full keyboard transparency, so aren't really usable.

When the net gets ten times faster, it'll probably work ;)
 
> The next best solution is to religiously use rsync to update your home
> machine's working directories and then always rsync your @home edits
> back to your work machine for any CVS operations which you'll run by
> logging into your work machine just as you did with 'vi'.
> 

Considered this too, just don't know if I trust myself that much, I've 
already lost work once this way.  Spose I'm just not that religious.

> >  I'm currently considering sshfs, but the performance won't be
> > good.
> 
> Use rsync over ssh!  :-)
> 

Wouldn't have done it any other way ;)

> > I assume many of you have this same problem, how do you deal with it?
> 
> I for one have _never_ had this problem.  I always login to the machine
> where I'm doing my development.  I run my development environment
> (normally Emacs) from that machine and only use the machine in front of
> me as a terminal.  Over high-speed connections I use Emacs as an X11
> client and over low-speed or high-latency connections I use Emacs in the
> good old-fashioned terminal mode.
> 
> The third best solution would be to get a laptop and always use it --
> i.e. carry your working directories and IDE with you wherever you go to
> work on them.
> 

Yeah, I love laptops, but not like I love my desktop...



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

Re: Auth using PAM

[Cary Coulter]

this is a 1Ghz P3 w/512mb.  No SMB being used for local passwd auth.

Can't believe this is TOO slow.


- Original Message - 
From: "Patton, Matthew E., CTR, OSD-PA&E" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, December 02, 2003 10:05 AM
Subject: RE: Auth using PAM


> Classification: UNCLASSIFIED
>
> > -Original Message-
> > From: Cary Coulter [mailto:[EMAIL PROTECTED]
>
> > Is there just something wrong with the ssh setup?
> > Personally, I have always
> > experienced a slower login with ssh versus telnet.
>
> you have a slow machine. Telnet does ZERO encryption - that's why it's
> fast!! For every SSH session the two ends have to generate session keys at
> the very least, plus there is the overhead of key exchange if you use key
> based auth etc. Then if you do SMB on top of that, then the SMB layer
> (curtesy of PAM) has to generate it's own packets and network traffic to
> auth you.
>
>
> ___
> 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 Version CHange

[Larry Jones]

Jim.Hyslop writes:
>
> If that's the case, then why was the revision number ever exposed in the
> first place? Is it a legacy of RCS or SCCS - do they not support symbolic
> tags?

I cannot say for sure, but presumably it's exposed in CVS because it was
exposed in RCS, which was the model (as well as the basis) for CVS.

> So are you saying that "cvs ci -r " is a mistake and should
> not have been allowed?

I wouldn't go that far, I'm just saying it should never be *used*.  :-)

It's the camel's nose into the tent.  The revision numbers are just for
internal bookkeeping; people who want to muck about with them expect
them to have some external significance and keep mucking about with
them to try to make that fantasy into reality.  It's better to disabuse
them of the notion as soon as possible rather than let them spend a
great deal of time on a fool's errand.

-Larry Jones

You're going to be pretty lonely in the nursing home. -- Calvin


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

Re: cvs rlog -rTAG1::TAG2 doesn't handle newly added files

[Larry Jones]

Matthew Herrmann writes:
> 
> I upgraded to 1.11.9 but this didn't solve the problem.

Sorry, I knew there were a number of fixes to that code and I was hoping
that they would fix the problem.  Now that I think about it a bit more,
however, I don't think it's fixable.  I don't think there's any way for
CVS to intuit, in the general case, what a missing tag should mean.  For
example, if it's the end tag that is missing and there's more than one
branch past the start tag, which branch should CVS follow?

-Larry Jones

Oh, now don't YOU start on me. -- Calvin


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

Re: Problems with uncommitted working directories, from home and

[Larry Jones]

Jim.Hyslop writes:
>
> this can get cumbersome, because IIRC you must remove all revisions
> from a branch before you can remove the symbolic branch tag

Nope.  Some might consider this a bug, but CVS is perfectly willing to
let you remove (or move) a branch tag at any time.  Of course, it then
becomes somewhat tricky to access any revisions that were on the branch
since there is no longer a branch tag pointing to them, but you can
always access them using the numeric revision number.

-Larry Jones

What a waste to be going to school on a morning like this. -- Calvin


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

Re: Auth using PAM

[Ed Avis]

"Cary Coulter" <[EMAIL PROTECTED]> writes:

>It appears that each time I click on a different file in the tree for
>a diff, it must reauthenticate to ssh, which in all reality, takes a
>two or more seconds longer than the pserver method.

You could try .

-- 
Ed Avis <[EMAIL PROTECTED]>



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

RE: Problems with uncommitted working directories, from homeand w ork.

[Jim.Hyslop]

Larry Lords [mailto:[EMAIL PROTECTED] wrote:
> I have a question on Jim's statement "Private branches are 
> never considered
> candidates for releases or for builds".  I have always 
> understood that a company
> would always release from a private branch.  This assumes 
> when a release process
> begins a release branch is created and final testing begins 
> on the release
> branch's code while development for succeeding releases 
> continue on the trunk. 
Usually, yes. In a perfect world, the code would not require any fixes or
fine-tuning after being released to QA, so the branch would never get used.
In real life, though, that tends to be how it works.

[...]

> Is this concept incorrect or is there a difference between 
> within cvs between a
> private branch and a non-import branch?

I think maybe there's a confusion in terminology here. CVS itself does not
have any concept of a "private branch". As far as CVS is concerned, the
private branch I described and the release branch you described are both
branches, and CVS treats them exactly the same. What distinguishes the two
types of branches is _how_ they are used.

By convention (the one I'm suggesting, I don't know if this is a standard
practise or not), anything checked into a branch that is designated as a
private branch is not considered a candidate for release or for builds.
Anything checked into a release branch is a candidate.

-- 
Jim Hyslop
Senior Software Designer
Leitch Technology International Inc. (http://www.leitch.com)
Columnist, C/C++ Users Journal (http://www.cuj.com/experts)



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

RE: CVS Version CHange

[Greg A. Woods]

[ On Tuesday, December 2, 2003 at 10:47:46 (-0500), Jim.Hyslop wrote: ]
> Subject: RE: CVS Version CHange
>
> If that's the case, then why was the revision number ever exposed in the
> first place? Is it a legacy of RCS or SCCS - do they not support symbolic
> tags?

I don't mean to answer for Larry, but I will put my two cents in:

It's almost impossible not to "expose" the RCS-Id in a system like CVS.

RCS obviously does support symbolic tags -- they are used to implement
CVS' symbolic tags.

SCCS does not support symbolic tags.  It would be almost impossible to
implement some of the internal features of CVS on SCCS, such as lazy
branch creation, let alone any of the tagging support (without also
using some additional database of sorts).  SCCS has a very rigid and
limited (though very simple, elegant, and reasonably easy to use),
revision, release, and branch numbering scheme dictated by the structure
of its ID numbers.  Many of us over the years have written and used, and
some of us still use, ad hoc front-ends to SCCS that give much of the
utility of CVS (handling trees of files uniformly, and even
copy-edit-merge concurrency).

> So are you saying that "cvs ci -r " is a mistake and should
> not have been allowed?

Absolutely!  ;-)

However the authors of CVS-II were not afraid to expose/implement many
experimental features just to see how they might be used.  CVS
throughout its history has been a very experimental and evolving system.
There's always been lots of variety of ropes in and around it with which
one might hang one's self.

In CVS the release number of RCS-Id is like any useless and almost
atrophied organ -- however it's impossible to give it up without
also giving up backwards compatability of the internal repository
structure.

Perhaps CVS should just hide the "1." from view, though doing that in
the RCS keyword expansion would be fraught with problems too and it may
still be needed in many command-line parameters.  Perhaps translating it
into a symbolic value such as "TRUNK." wherever visible would be better.

> I agree that tags should be the _preferred_ way to do this, but I really do
> not see why you are so vehemently opposed to manually forcing revision
> numbers under special circumstances. What problems will this introduce?

I don't remember all the internal details of the issues but I do
remember that the first time I tried this silly trick as an experiment
those issues became quite obvious within a few moments of play.

> Again, under special circumstances, not under day-to-day use.

The problem is that once it's been done then it becomes an every-day
issue from then to the end of the life of the repository (unless it's
undone, of course).

> The major drawback with tags is that they can be moved or deleted, without
> any history of the changes.

If these sorts of things worry you then perhaps CVS is not the right
tool for your needs.  :-)

CVS is not very much of a policy enforcement tool, if any of one at all.
(despite the abilities of features such as "taginfo" scripting hooks)

RCS (and thus CVS) do not track changes to much of the meta information,
and, as you said in the text I deleted, there's a good deal of important
meta information kept by RCS that's not ``fixed'' in the internal
structure of an RCS file either.

-- 
Greg A. Woods

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


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

Re: Problems with uncommitted working directories, from homeand work.

[Eric Siegerman]

On Tue, Dec 02, 2003 at 11:04:54AM -0700, Larry Lords wrote:
> I have a question on Jim's statement "Private branches are never considered
> candidates for releases or for builds".

The operative word is "private".

> I have always understood that a company
> would always release from a private branch.

No; from a *non*-private branch.  Other than that detail, your
description of a branch-based release process sounds bang on.

CVS doesn't distinguish between private and non-private branches;
from its point of view they're all just "cvs tag -b "
branches.  The only difference is in your intention in creating
thebranch, and thus what you subsequently do with it; CVS doesn't
know or care.  Hence Jim's suggestion of a naming scheme so your
team can keep all those different-purposed branches straight.

(Vendor branches, which of course CVS does treat specially, don't
come into this discussion at all.)

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
It must be said that they would have sounded better if the singer
wouldn't throw his fellow band members to the ground and toss the
drum kit around during songs.
- Patrick Lenneau


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

RE: Problems with uncommitted working directories, from homeand work.

[Paul Sander]

There are private branches, and there are private branches.  In the context
that you describe, the integration branch is private to the builders who
gate the release of the product.  Jim refers instead to a branch that's
private to the developer performing the work.

Branches are a general tool for isolating work.  The nature of that work
can vary from user to user.

--- Forwarded mail from [EMAIL PROTECTED]

I have a question on Jim's statement "Private branches are never considered
candidates for releases or for builds".  I have always understood that a company
would always release from a private branch.  This assumes when a release process
begins a release branch is created and final testing begins on the release
branch's code while development for succeeding releases continue on the trunk. 
Any problems found on the release branch are fixed and retested.  Only approved
bug fixes are checked into the release branch.  When the release branch is
stable the release is made from the branch and all changes are merged into the
trunk.

Is this concept incorrect or is there a difference between within cvs between a
private branch and a non-import branch?

--- End of forwarded message from [EMAIL PROTECTED]



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

RE: CVS Version CHange

[Greg A. Woods]

[ On Monday, December 1, 2003 at 10:18:19 (-0500), Jim.Hyslop wrote: ]
> Subject: RE: CVS Version CHange
>
> On the other hand, the developers may want to take the current state of the
> repository, and assign it a known starting point, such as 2.0. This is
> entirely reasonable.

No, it's not really.  It's a bad idea to change even the first number in
any RCS-Id when using CVS, even if done across a project.

RCS-Id numbers are for internal use _only_ in CVS.

> I strongly recommend that this be used *only* for the scenario I outlined -

I _strongly_ recommend that it _NEVER_ be done when using CVS.

There should be more detailed discussion about the issues in the archives.

-- 
Greg A. Woods

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


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

Re: Problems with uncommitted working directories, from home and work.

[Greg A. Woods]

[ On Wednesday, December 3, 2003 at 02:12:59 (+1100), Craig O'Shannessy wrote: ]
> Subject: Problems with uncommitted working directories, from home and work.
>
> I never had this problem before, I've been using ssh and vi for years,
> but now I'm addicted to an IDE (idea), so I've gotta find a better
> solution.

Is "idea" an X11 application?  If so then how about X11 forwarding
through SSH?  I.e. run it on your work machine just as you did with 'vi'.

The next best solution is to religiously use rsync to update your home
machine's working directories and then always rsync your @home edits
back to your work machine for any CVS operations which you'll run by
logging into your work machine just as you did with 'vi'.

>  I'm currently considering sshfs, but the performance won't be
> good.

Use rsync over ssh!  :-)

> I assume many of you have this same problem, how do you deal with it?

I for one have _never_ had this problem.  I always login to the machine
where I'm doing my development.  I run my development environment
(normally Emacs) from that machine and only use the machine in front of
me as a terminal.  Over high-speed connections I use Emacs as an X11
client and over low-speed or high-latency connections I use Emacs in the
good old-fashioned terminal mode.

The third best solution would be to get a laptop and always use it --
i.e. carry your working directories and IDE with you wherever you go to
work on them.

-- 
Greg A. Woods

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


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

Re: Problems with uncommitted working directories, from home and work.

[Paul Sander]

I've applied two approaches to address this problem that can be implemented
readily with CVS:

The first method is to use a personal branch for your own development and
periodically merge to the main branch.  This is a standard pattern of use
in CVS.

The second is to divorce the notion of "committed code" from "good code",
allowing the developers to commit at will.  Then have a mechanism to
identify the good code and only use that outside the developer's workspace.
This can be crudely implemented with tags, but I used changesets implemented
with the submit/assemble method that has been discussed in this forum
several times in the past.

--- Forwarded mail from [EMAIL PROTECTED]

I work onsite about half the time and offsite the other half.  Some
nights, I'll be onsite, be half way through a complex set of changes,
have heaps of modified files, and have to go home.

The next morning, I want to pick up from where I left off, but this time
from home.  I can't commit the stuff at work (at least to the head
branch), because it's not stable enough (may not even build).

I'm currently using a shell script cludge that scp's the modified and
new files over to my home PC, and then I have to remember to do the
oposite before going back onsite.

--- End of forwarded message from [EMAIL PROTECTED]



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

RE: Problems with uncommitted working directories, from homeand work.

[Larry Lords]

I have a question on Jim's statement "Private branches are never considered
candidates for releases or for builds".  I have always understood that a company
would always release from a private branch.  This assumes when a release process
begins a release branch is created and final testing begins on the release
branch's code while development for succeeding releases continue on the trunk. 
Any problems found on the release branch are fixed and retested.  Only approved
bug fixes are checked into the release branch.  When the release branch is
stable the release is made from the branch and all changes are merged into the
trunk.

Is this concept incorrect or is there a difference between within cvs between a
private branch and a non-import branch?

Just wondering,
Larry Lords

>>> Jim.Hyslop <[EMAIL PROTECTED]> 12/02/03 09:04AM >>>
Craig O'Shannessy [mailto:[EMAIL PROTECTED] wrote:
> I work onsite about half the time and offsite the other half.  Some
> nights, I'll be onsite, be half way through a complex set of changes,
> have heaps of modified files, and have to go home.
> 
> The next morning, I want to pick up from where I left off, 
> but this time
> from home.  I can't commit the stuff at work (at least to the head
> branch), because it's not stable enough (may not even build).
This is where "private branches" come in. Private branches are never
considered candidates for releases or for builds. The contents of private
branches are potentially meaningless, except to the person who created them.

We use a naming convention for private branches: the name starts with
"priv-" and contains something identifying the developer. Since you are
using the branch to effectively transfer files between home and work, you
might use:

cvs tag -b priv-craig-transfer

When you are ready to go home, check everything into the private branch.
When you resume work from home, then there are a couple of ways you can
proceed.

1) You can work from the trunk, by immediately merging your private branch
into your trunk code. This will allow you to immediately update any changes
anybody else checks in. The drawback is, if you aren't ready to check in by
the end of the day, you have to create another branch or move the existing
branch (this can get cumbersome, because IIRC you must remove all revisions
from a branch before you can remove the symbolic branch tag - might just be
easier to use branch tags keyed by date, e.g. priv-craig-transfer-20031202).

2) You can work from the branch, and merge any changes anyone checks in
during the day into your code, and when you're done merge it back to the
trunk. In other words, treat it like any normal branch.

My inclination would be to use the first approach. But do whatever works
best for you.

-- 
Jim Hyslop
Senior Software Designer
Leitch Technology International Inc. (http://www.leitch.com)
Columnist, C/C++ Users Journal (http://www.cuj.com/experts)



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


--
This message may contain confidential information, and is intended only for the use of 
the individual(s) to whom it is addressed.


==



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

Re: Problems with uncommitted working directories, from home and work.

[Maarten de Boer]

> I can't commit the stuff at work (at least to the head
> branch), because it's not stable enough (may not even build).

So the obvious answer is: use a branch to do your unstable
commits!

You should do that anyway, because it sounds to be that you are making
changes that go uncommited for a long time.

Maarten






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

RE: Problems with uncommitted working directories, from home and work.

[Jim.Hyslop]

Craig O'Shannessy [mailto:[EMAIL PROTECTED] wrote:
> I work onsite about half the time and offsite the other half.  Some
> nights, I'll be onsite, be half way through a complex set of changes,
> have heaps of modified files, and have to go home.
> 
> The next morning, I want to pick up from where I left off, 
> but this time
> from home.  I can't commit the stuff at work (at least to the head
> branch), because it's not stable enough (may not even build).
This is where "private branches" come in. Private branches are never
considered candidates for releases or for builds. The contents of private
branches are potentially meaningless, except to the person who created them.

We use a naming convention for private branches: the name starts with
"priv-" and contains something identifying the developer. Since you are
using the branch to effectively transfer files between home and work, you
might use:

cvs tag -b priv-craig-transfer

When you are ready to go home, check everything into the private branch.
When you resume work from home, then there are a couple of ways you can
proceed.

1) You can work from the trunk, by immediately merging your private branch
into your trunk code. This will allow you to immediately update any changes
anybody else checks in. The drawback is, if you aren't ready to check in by
the end of the day, you have to create another branch or move the existing
branch (this can get cumbersome, because IIRC you must remove all revisions
from a branch before you can remove the symbolic branch tag - might just be
easier to use branch tags keyed by date, e.g. priv-craig-transfer-20031202).

2) You can work from the branch, and merge any changes anyone checks in
during the day into your code, and when you're done merge it back to the
trunk. In other words, treat it like any normal branch.

My inclination would be to use the first approach. But do whatever works
best for you.

-- 
Jim Hyslop
Senior Software Designer
Leitch Technology International Inc. (http://www.leitch.com)
Columnist, C/C++ Users Journal (http://www.cuj.com/experts)



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

Re: Auth using PAM

[Geoff Beier]

On Tue, Dec 02, 2003 at 08:58:36AM -0600, Cary Coulter wrote:
> I have tried ssh.  It does work, will auth throuch pam_smb_auth using NT
> passwords, not Unix ones.
> 
> However,  I do experience a significant delay when invoking CVS for ssh
> authorization (shows on the WSAD dialog box).  The delay isn't too bad for
> normal repository operations, (synchronizing, updating, commiting), but
> becomes excessive when looking at multiple file diffs through the internal
> diff browser.
[explanation snipped]
> Is there just something wrong with the ssh setup?  Personally, I have always
> experienced a slower login with ssh versus telnet.
> 

It may be that sshd is doing name lookups for clients. Assuming that you
are not using any sort of hostname-based authentication, you should be
able to disable these lookups... consult your sshd documentation to see
how. (On mine, you set VerifyReverseMapping to No in the sshd_config
file and start the daemon with the -u0 option.)

HTH,

Geoff


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

RE: Auth using PAM

Classification: UNCLASSIFIED

> -Original Message-
> From: Cary Coulter [mailto:[EMAIL PROTECTED]

> Is there just something wrong with the ssh setup?  
> Personally, I have always
> experienced a slower login with ssh versus telnet.

you have a slow machine. Telnet does ZERO encryption - that's why it's
fast!! For every SSH session the two ends have to generate session keys at
the very least, plus there is the overhead of key exchange if you use key
based auth etc. Then if you do SMB on top of that, then the SMB layer
(curtesy of PAM) has to generate it's own packets and network traffic to
auth you.


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

Re: Auth using PAM

[Maarten de Boer]

> Is there just something wrong with the ssh setup?  Personally, I have always
> experienced a slower login with ssh versus telnet.

Yes, it sounds to me as if something is wrong with your setup. Try running 
the ssh server in debug mode, and the client in verbose mode, to see where the
delay comes from. By using a different port you can do this without disturbing
the working ssh server:

[EMAIL PROTECTED]:$ sshd -d -p 

[EMAIL PROTECTED]:$ ssh -v -p  server

Maarten




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

Re: Error

[Larry Jones]

"Ford, Karen (MED, Contractor)" writes:
> 
> > cvs [server aborted]: error writing to lock file /myfilename

Please don't edit error messages -- quote them verbatim.  I'm reasonably
sure that should have been something more along the lines of
",myfilename" rather than "/myfilename", which would have allowed me to
answer your question without having to consult the source code.

> Could the addition of the tag have put it over the file size limit?

Yes.  That error message occurs when there is an error writing the new
RCS file (the lock file is an RCS lock file, not a CVS lock file).  If
you have enough disk space to hold a second copy of the file, the most
likely problem is a quota of some sort.

-Larry Jones

Whatever it is, it's driving me crazy! -- Calvin


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

RE: CVS Version CHange

[Jim.Hyslop]

[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] wrote:
[specifying revision numbers on checkin - is it reasonable?]

> No, it is not.  Revision numbers are for CVS's internal use 
> only;
If that's the case, then why was the revision number ever exposed in the
first place? Is it a legacy of RCS or SCCS - do they not support symbolic
tags?

So are you saying that "cvs ci -r " is a mistake and should
not have been allowed?

> people
> should ignore them and resist the temptation to muck with 
> them.  If you
> want to mark a known starting point (or anything else), use a tag.
I agree that tags should be the _preferred_ way to do this, but I really do
not see why you are so vehemently opposed to manually forcing revision
numbers under special circumstances. What problems will this introduce?
Again, under special circumstances, not under day-to-day use. I admit, I
cannot think of any real-life reason I'd want to do it, but that doesn't
mean I should be prohibited from using the revision numbers if I come up
with a reason to do so.

The major drawback with tags is that they can be moved or deleted, without
any history of the changes. You cannot change a revision number, unless you
want to go through a lot of work (or unless you feel like manually editing
the RCS file - definitely not a recommended practise!!).

-- 
Jim Hyslop
Senior Software Designer
Leitch Technology International Inc. (http://www.leitch.com)
Columnist, C/C++ Users Journal (http://www.cuj.com/experts)



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

Re: Main branch tips

[Larry Jones]

[EMAIL PROTECTED] writes:
> 
> For any branch but the main one I can refer to latest source code versions 
> using simply the branch name.
> Is there some way (or special tag) which will allow me to refer to the 
> "tips" of main branch, so I can use:
> cvs diff -r some_branch -r main_branch

For most things you can use "HEAD", but diff takes "HEAD" to mean the
head of the current branch rather than the head of the trunk.  Unless
you've mucked with the revision numbers, the trunk will be branch 1, so
you can use the revision "1" to refer to it.

-Larry Jones

Your gender would be a lot more tolerable if it wasn't so darn cynical!
-- Calvin


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

Re: Limitation on --allow-root pserver options?

[Larry Jones]

Mark writes:
> 
> Currently we have 58 --allow-root options setup in the wrapper script.

Why do you have so many separate repositories?  Can't you just use
modules in a single repository?

> Is this a solaris limitation or a cvs limitation (there are about 2513
> characters that make up the --allow-root argument string, excluding any
> spaces)?

There is no limit in CVS.

-Larry Jones

The authorities are trying to silence any view contrary to their own!
-- Calvin


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

Re: CVS Version CHange

[Larry Jones]

Jim.Hyslop writes:
> 
> On the other hand, the developers may want to take the current state of the
> repository, and assign it a known starting point, such as 2.0. This is
> entirely reasonable.

No, it is not.  Revision numbers are for CVS's internal use only; people
should ignore them and resist the temptation to muck with them.  If you
want to mark a known starting point (or anything else), use a tag.

-Larry Jones

Oh yeah?  You just wait! -- Calvin


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

Re: Main branch tips

[Maarten de Boer]

> So, if I do a cvs checkout without a -r then I get the HEAD revision?

yes.

> And in that case there will be no difference between 'cvs update -j ' 
> and 'cvs update -j  -j HEAD' ?
> 
> Is that correct?

yes.



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

Problems with uncommitted working directories, from home and work.

[Craig O'Shannessy]

Hi,

I'm finding this problem a bit hard to explain in a few words, and
aren't having much luck with search engines finding an answer.
I work onsite about half the time and offsite the other half.  Some
nights, I'll be onsite, be half way through a complex set of changes,
have heaps of modified files, and have to go home.
The next morning, I want to pick up from where I left off, but this time
from home.  I can't commit the stuff at work (at least to the head
branch), because it's not stable enough (may not even build).
I'm currently using a shell script cludge that scp's the modified and
new files over to my home PC, and then I have to remember to do the
oposite before going back onsite.
I never had this problem before, I've been using ssh and vi for years,
but now I'm addicted to an IDE (idea), so I've gotta find a better
solution.  I'm currently considering sshfs, but the performance won't be
good.
I assume many of you have this same problem, how do you deal with it?
I'm also considering using a different VCS system in conjunction with
CVS, that is JUST for syncing home and work (maybe RCS?).
I'd be very interested in anyones experiences.

Craig



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

Re: Main branch tips

[Maarten de Boer]

Don't listen to me, listen to Jim! Sorry for the mistake.

> > So, if I do a cvs checkout without a -r then I get the HEAD revision?
> 
> yes.

(only if it is a CLEAN checkout)

> > And in that case there will be no difference between 'cvs update -j ' 
> > and 'cvs update -j  -j HEAD' ?
> > 
> > Is that correct?
> 
> yes.

NO (I misread the question)



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

Re: Auth using PAM

[Cary Coulter]

I have tried ssh.  It does work, will auth throuch pam_smb_auth using NT
passwords, not Unix ones.

However,  I do experience a significant delay when invoking CVS for ssh
authorization (shows on the WSAD dialog box).  The delay isn't too bad for
normal repository operations, (synchronizing, updating, commiting), but
becomes excessive when looking at multiple file diffs through the internal
diff browser.

It appears that each time I click on a different file in the tree for a
diff, it must reauthenticate to ssh, which in all reality, takes a two or
more seconds longer than the pserver method.  While this isn't a
show-stopper, it is a long time to wait when looking a multiple file diffs.

The ssh delay is present for both a passwd/shadow authenticated user as well
as the pam_smb_auth user, so I don't think the delay comes from the remote
auth method.

Is there just something wrong with the ssh setup?  Personally, I have always
experienced a slower login with ssh versus telnet.

Thanks for the help.
Cary




- Original Message - 
From: "Maarten de Boer" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, December 02, 2003 3:53 AM
Subject: Re: Auth using PAM


> Cary Coulter wrote:
> > Is there a patch for 1.11.6 CVS for using PAM on Linux for user
> > authentication?   We're using WSAD/Eclipse and understand the 1.11.6
> > is as new as we can go for now.
>
> I really think you don't want to do this. It is a lot better (a lot more
> secure) to use CVS through ssh. I am not familiar however with
WSAD/Eclipse,
> but I suppose you can configure it to use a external remote shell
connection
> (:ext:) instead of pserver.
>
> > Our main development platform is Windows. I have a Linux machine using
> > pam_smb_auth to authenticate logins via our NT domain for the "Windows
> > only" users.  Regular Unix users use the shadow file.  All user/group
> > info is in /etc/passwd and /etc/shadow, only the passwords come from
> > NT.
>
> Our CVS server is Linux, the password are on a SAMBA server, the clients
> use CVS through ssh (mostly using the excellent CVS gui client LinCVS,
> also for Windows), the CVS server authenticates the ssh login using the
> pam_smb_auth module. (And the shells on the CVS server are very limited
> chrooted shells that only allow to execute cvs)
>
> Maarten
>
>


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

RE: Main branch tips

[Jim.Hyslop]

Andy Jones [mailto:[EMAIL PROTECTED] wrote:
> > > Is there some way (or special tag) which will allow me to 
> refer to the
> > > "tips" of main branch, so I can use:
> >
> >yes, there is a special tag, HEAD
Be aware that with the diff command, HEAD means "the head revision of the
currently-checked-out branch" (in this context, "branch" also includes the
trunk). For all other commands, HEAD means the head revision of the trunk.

> >(and another one is BASE, which refers to the revision you last checked
> >out in your current working directory)

> So, if I do a cvs checkout without a -r then I get the HEAD revision?
Maybe. If the source is already checked out using a tag, then it uses the
tag, e.g.:

cvs co -ratag amodule
cvs co amodule

The second checkout will still use the tag 'atag'.

> And in that case there will be no difference between 'cvs 
> update -j ' 
> and 'cvs update -j  -j HEAD' ?
> 
> Is that correct?

No. 

With merging, it is the _first_ -j flag that is optional, and that does not
default to HEAD but to BASE (or, more accurately, to the "ancestor revision"
- the manual
http://www.cvshome.org/docs/manual/cvs-1.11.7/cvs_16.html#SEC153 defines
"ancestor revision" more succinctly than I can).

The first command merges the difference between the ancestor revision and
 into your source. The second command will merge the difference
between  and HEAD into your source.

-- 
Jim Hyslop
Senior Software Designer
Leitch Technology International Inc. (http://www.leitch.com)
Columnist, C/C++ Users Journal (http://www.cuj.com/experts)




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

Re: Suggestions for using CVS with a system/software project

[Dustin Puryear]

Thanks for the suggestions Mark.

We actually began importing the distribution version of externally developed
software that we modify (we import as SOFTWARE_VER_DIST), and then we check
in our changes on top of that. I made the decision to not note the version
of the distributed software in the directory, but just in the CVS log. So if
we import, say, Apache-1.3.25 I just import into:

projectname/components/apache/apache

Instead of:

projectname/components/apache/apache-1.3.25

I don't see a real need to note the original version in the directory name
itself. One reason to do this is that we may later on move to a newer
version and bring out changes over. That would require that we either delete
from CVS apache-1.3.25 and create the new directory, or leave the old
directory and create a new one. By using a directory without a version name
we can keep a consistent area for that code.

As far as software that we need but do not edit, I like the golden release
tarballs idea the best. Why check in code to CVS when you aren't going to
actually use the benefits of CVS? I suppose we can maintain a distribution
directory that runs parallel to CVS for the golden release tarballs:

/home/cvsroot
/home/goldenrelease

When I do a 'make install' under projectname my Makefile will know to grab
files from /home/goldenrelease as well as compile code from CVS.

So instead of having thirty to forty software packages from ports under CVS,
we will have only what we customize, and everything else goes into
/home/goldenrelease (or wherever).

Thoughts on this?



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

Re: Limitation on --allow-root pserver options?

[David Wood]

You could consider using xinetd alongside Solaris inetd (just for the CVS 
port). It would be a simple experiment to set it up and see if it, too, 
exhibits the problem. 

[EMAIL PROTECTED] wrote on 12/02/2003 
03:38:25 AM:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Mark <[EMAIL PROTECTED]> writes:
> 
> > We have cvs pserver 1.11.1p1 setup on solaris 2.8 and a wrapper script
> > in /etc/inetd.conf to allow many --allow-roots (we have many
> > apps/groups/business units we provide CM support for, thus the need to
> > many repos). We use WinCVS 1.3 for the client.
> 
> Okay. However, there are many bug fixes to cvs available in the latest
> cvs 1.11.9 version of cvs.
> 
> > Currently we have 58 --allow-root options setup in the wrapper script.
> > The 58th --allow-root does not work/is not recognized.
> > 
> > When we try to login via pserver:
> > - the client gets "no such repository" message
> > - the server logs a "login refused for" in /var/adm/messages 
> > 
> > When I moved that 58th -allow-root to the top of the -allow-root list,
> > it worked, but then the new last one in the list, now has the above
> > described issues.
> 
> Well, clearly some problem is being uncovered. If you are able to
> upgrade to a newer version of cvs and still have the problem, then
> it may be possible to help you debug the problem on this list.
> 
> > Is this a solaris limitation or a cvs limitation (there are about 2513
> > characters that make up the --allow-root argument string, excluding 
any
> > spaces)?
> 
> I am not aware of such a limitation, however, you could test it 
yourself.
> Take a simple program like this:
> 
> % cat testit.c
> #include 
> int main(int argc, char *argv[]) {
> int i; for ( i = 0; i < argc; i++ ) printf("%d: %s\n", i, argv[i]);
> return(0);
> }
> %
> 
> Compile it and give it all of the arguments you setup in your wrapper
> script for cvs and see what happens.
> 
> > I could use different ports on the server to balance out the
> > repositories but WinCVS 1.3 doesn't retain port info inside the
> > CVS admin subdirectory files in the workares which causes problems
> > for users who have to work out of repos on different ports at the same
> > time. (ie. instead of WinCVS 1.3 gathering all it needs from a
> > workarea's CVS subdir to commit/update etc... it uses the current port
> > settings in the WinCVS preferences regardless of what the workarea is
> > currently being used this is quite annoying and confusing)... if
> > this issues has been fixed in WinCVS 1.3, please let me know.
> > 
> > Any help/insight/suggestions is appreciated. yes we only have one
> > solaris server to use, and yes we must have independent
> > repositories..
> > 
> > Thanks,
> > 
> > Mark
> 
>Good luck,
>-- Mark
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.3 (FreeBSD)
> 
> iD8DBQE/zE+B3x41pRYZE/gRAsJMAJsGOsCUaYAUE++6sIWazSnGfHTV9ACdFVck
> Lyqb6jf6h+thjyzNIlIJkUY=
> =3nB/
> -END PGP SIGNATURE-
> 
> 
> ___
> 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: Suggestions for using CVS with a system/software project

[Jim.Hyslop]

Dustin Puryear [mailto:[EMAIL PROTECTED] wrote:
> Well that's weird. I had sent one that didn't seem to post, 
> then sent a
> second copy, and now they both show up. I waited several hours before
> reposting, honest!
Yeah, there seems to have been some delay at gnu.org, judging from the SMTP
headers. I sent a message yesterday at around 10:20 a.m. and it didn't show
up until 6:30 this morning.

Good thing I remembered (for once) to read through all my inbox before
lecturing you about this not being a chat group ;=)

-- 
Jim Hyslop
Senior Software Designer
Leitch Technology International Inc. (http://www.leitch.com)
Columnist, C/C++ Users Journal (http://www.cuj.com/experts)


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

Re: Main branch tips

[Andy Jones]

> Is there some way (or special tag) which will allow me to refer to the
> "tips" of main branch, so I can use:
yes, there is a special tag, HEAD

(and another one is BASE, which refers to the revision you last checked
out in your current working directory)
So, if I do a cvs checkout without a -r then I get the HEAD revision?

And in that case there will be no difference between 'cvs update -j ' 
and 'cvs update -j  -j HEAD' ?

Is that correct?



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

Re: Main branch tips

[Maarten de Boer]

> Is there some way (or special tag) which will allow me to refer to the 
> "tips" of main branch, so I can use:

yes, there is a special tag, HEAD

(and another one is BASE, which refers to the revision you last checked
out in your current working directory)






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

Main branch tips

[Jacek_Wolski]

Hello,
For any branch but the main one I can refer to latest source code versions 
using simply the branch name.
Is there some way (or special tag) which will allow me to refer to the 
"tips" of main branch, so I can use:
cvs diff -r some_branch -r main_branch

Cheers,

Jacek



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

Re: Auth using PAM

[Maarten de Boer]

Cary Coulter wrote:
> Is there a patch for 1.11.6 CVS for using PAM on Linux for user
> authentication?   We're using WSAD/Eclipse and understand the 1.11.6
> is as new as we can go for now.

I really think you don't want to do this. It is a lot better (a lot more
secure) to use CVS through ssh. I am not familiar however with WSAD/Eclipse,
but I suppose you can configure it to use a external remote shell connection
(:ext:) instead of pserver.

> Our main development platform is Windows. I have a Linux machine using
> pam_smb_auth to authenticate logins via our NT domain for the "Windows
> only" users.  Regular Unix users use the shadow file.  All user/group
> info is in /etc/passwd and /etc/shadow, only the passwords come from
> NT.

Our CVS server is Linux, the password are on a SAMBA server, the clients
use CVS through ssh (mostly using the excellent CVS gui client LinCVS,
also for Windows), the CVS server authenticates the ssh login using the
pam_smb_auth module. (And the shells on the CVS server are very limited
chrooted shells that only allow to execute cvs)

Maarten



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

Re: Suggestions for using CVS with a system/software project

[Mark D. Baushke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dustin Puryear <[EMAIL PROTECTED]> writes:

> I have a project that combines custom software, FreeBSD, and some software
> initially grabbed from FreeBSD ports. (We use the FreeBSD ports version
> because any FreeBSD-patches to the software have been done for us.) We do
> not use new versions of any software from ports unless we do thorough
> testing--we would rather keep to a single version of each software so that
> we know about the bugs, specific implementation, etc. In addition, we
> customize some ports packages, so grabbing the latest and greatest isn't
> beneficial.
> 
> The proposed CVS layout that I have so far is as follows:
> 
> projectname/kernel
> projectname/tools/X
> projectname/tools/Y
> projectname/tools/Z
> projectname/userinterface
> projectname/component/softwareX
> projectname/component/softwareY
> projectname/component/softwareZ
> ...
> 
> Anything under projectname/tools/ is custom. In addition, various software
> under projectname/component/ may be custom developed, customized from ports,
> or customized from downloaded source. By 'component' I mean to imply that
> this software works together in some fashion to deliver a service, or is in
> some way a core component of the software. projectname/kernel/ is a
> customized FreeBSD kernel.
> 
> In my mind, we have three types of software to worry about:
> 
> 1. custom developed - goes into CVS just like any custom software package
> being developed.

Sure.

> 2. customized, existing software - if we are grabbing the software from
> ports should we just check that into CVS like we would with any other
> customized source? 

You will probably find it easier to import the baseline version and then
commit your code on top of it.

> I would say that we are relying on 20-30 ports packages
> (we only need a few services, but the dependencies grab a lot of other
> software). So in this case we need to check in 20-30 source packages? 

Sure.

> If we decide to grab a new release from ports we would just check that
> in on top of the existing source? 

Or, import it and then do a merge of your changes forward.

> Should we consider a special directory for this?

Possibly. FreeBSD uses a contrib hierarchy in their src tree to allow
themselves to have the Makefile glue kept separately.

> projectname/kernel
> projectname/tools/X
> projectname/tools/Y
> projectname/tools/Z
> projectname/component/softwareX
> projectname/component/softwareY
> projectname/component/softwareZ
> projectname/freebsd-ports/softwareX
> projectname/freebsd-ports/softwareY
> projectname/freebsd-ports/softwareZ
> ...
> 
> 3. non-customized, existing software
> 
> We have some software that we use from ports, and we depend on
> specific versions. Should we just keep a copy of tgz in an archive
> outside of CVS, or should we insert this into CVS too? 

That is up to you, you might find it useful to keep it in cvs as a
source reference, but keeping 'golden' release tarballs has its place as
well.

> Often, we just install the software and then one of our tools creates
> a customized configuration for it. Should we be checking in the
> configuration files then? Our tools overwrite them anyway, and we
> aren't really customized the configuration files by hand.

That is hard to say... there are arguments for both positions. If the
'seed' configuration might be used in a vanilla way and might change
later, you might want to understand why and when those changes to the
initial configuration were introduced and/or have a process to audit
what changes have been made to your product over time.

-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQE/zEIZ3x41pRYZE/gRAmPEAKDd5YyENEGTVgrBxHLea4Mj//KZYgCeJxCB
X42H8SsRd6noB2Gn0WvRWoA=
=cLHo
-END PGP SIGNATURE-


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

Re: Limitation on --allow-root pserver options?

[Mark D. Baushke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark <[EMAIL PROTECTED]> writes:

> We have cvs pserver 1.11.1p1 setup on solaris 2.8 and a wrapper script
> in /etc/inetd.conf to allow many --allow-roots (we have many
> apps/groups/business units we provide CM support for, thus the need to
> many repos). We use WinCVS 1.3 for the client.

Okay. However, there are many bug fixes to cvs available in the latest
cvs 1.11.9 version of cvs.

> Currently we have 58 --allow-root options setup in the wrapper script.
> The 58th --allow-root does not work/is not recognized.
> 
> When we try to login via pserver:
> - the client gets "no such repository" message
> - the server logs a "login refused for" in /var/adm/messages 
> 
> When I moved that 58th -allow-root to the top of the -allow-root list,
> it worked, but then the new last one in the list, now has the above
> described issues.

Well, clearly some problem is being uncovered. If you are able to
upgrade to a newer version of cvs and still have the problem, then
it may be possible to help you debug the problem on this list.

> Is this a solaris limitation or a cvs limitation (there are about 2513
> characters that make up the --allow-root argument string, excluding any
> spaces)?

I am not aware of such a limitation, however, you could test it yourself.
Take a simple program like this:

% cat testit.c
#include 
int main(int argc, char *argv[]) {
int i; for ( i = 0; i < argc; i++ ) printf("%d: %s\n", i, argv[i]);
return(0);
}
%

Compile it and give it all of the arguments you setup in your wrapper
script for cvs and see what happens.

> I could use different ports on the server to balance out the
> repositories but WinCVS 1.3 doesn't retain port info inside the
> CVS admin subdirectory files in the workares which causes problems
> for users who have to work out of repos on different ports at the same
> time. (ie. instead of WinCVS 1.3 gathering all it needs from a
> workarea's CVS subdir to commit/update etc... it uses the current port
> settings in the WinCVS preferences regardless of what the workarea is
> currently being used this is quite annoying and confusing)... if
> this issues has been fixed in WinCVS 1.3, please let me know.
> 
> Any help/insight/suggestions is appreciated. yes we only have one
> solaris server to use, and yes we must have independent
> repositories..
> 
> Thanks,
> 
> Mark

Good luck,
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQE/zE+B3x41pRYZE/gRAsJMAJsGOsCUaYAUE++6sIWazSnGfHTV9ACdFVck
Lyqb6jf6h+thjyzNIlIJkUY=
=3nB/
-END PGP SIGNATURE-


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

Re: Suggestions for using CVS with a system/software project

[Dustin Puryear]

Well that's weird. I had sent one that didn't seem to post, then sent a
second copy, and now they both show up. I waited several hours before
reposting, honest!

- Original Message - 
From: "Dustin Puryear" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, December 01, 2003 9:07 AM
Subject: Suggestions for using CVS with a system/software project


> I am just now moving a project to CVS, and would like some suggestions.
I'm
> really just asking for your experiences in what works and what doesn't. I
> appreciate any input!
>
> I have a project that combines custom software, FreeBSD, and some software
> initially grabbed from FreeBSD ports. (We use the FreeBSD ports version
> because any FreeBSD-patches to the software have been done for us.) We do
> not use new versions of any software from ports unless we do thorough
> testing--we would rather keep to a single version of each software so that
> we know about the bugs, specific implementation, etc. In addition, we
> customize some ports packages, so grabbing the latest and greatest isn't
> beneficial.
>
> The proposed CVS layout that I have so far is as follows:
>
> projectname/kernel
> projectname/tools/X
> projectname/tools/Y
> projectname/tools/Z
> projectname/userinterface
> projectname/component/softwareX
> projectname/component/softwareY
> projectname/component/softwareZ
> ...
>
> Anything under projectname/tools/ is custom. In addition, various software
> under projectname/component/ may be custom developed, customized from
ports,
> or customized from downloaded source. By 'component' I mean to imply that
> this software works together in some fashion to deliver a service, or is
in
> some way a core component of the software. projectname/kernel/ is a
> customized FreeBSD kernel.
>
> In my mind, we have three types of software to worry about:
>
> 1. custom developed - goes into CVS just like any custom software package
> being developed.
>
> 2. customized, existing software - if we are grabbing the software from
> ports should we just check that into CVS like we would with any other
> customized source? I would say that we are relying on 20-30 ports packages
> (we only need a few services, but the dependencies grab a lot of other
> software). So in this case we need to check in 20-30 source packages? If
we
> decide to grab a new release from ports we would just check that in on top
> of the existing source? Should we consider a special directory for this?
>
> projectname/kernel
> projectname/tools/X
> projectname/tools/Y
> projectname/tools/Z
> projectname/component/softwareX
> projectname/component/softwareY
> projectname/component/softwareZ
> projectname/freebsd-ports/softwareX
> projectname/freebsd-ports/softwareY
> projectname/freebsd-ports/softwareZ
> ...
>
> 3. non-customized, existing software
>
> We have some software that we use from ports, and we depend on specific
> versions. Should we just keep a copy of tgz in an archive outside of CVS,
or
> should we insert this into CVS too? Often, we just install the software
and
> then one of our tools creates a customized configuration for it. Should we
> be checking in the configuration files then? Our tools overwrite them
> anyway, and we aren't really customized the configuration files by hand.
>
>
>
> ___
> 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

Limitation on --allow-root pserver options?

[Mark]

We have cvs pserver 1.11.1p1 setup on solaris 2.8 and a wrapper script in
/etc/inetd.conf to allow many --allow-roots (we have many apps/groups/business
units we provide CM support for, thus the need to many repos). We use WinCVS
1.3 for the client.

Currently we have 58 --allow-root options setup in the wrapper script. The 58th
--allow-root does not work/is not recognized.

When we try to login via pserver:
- the client gets "no such repository" message
- the server logs a "login refused for" in /var/adm/messages 

When I moved that 58th -allow-root to the top of the -allow-root list, it
worked, but then the new last one in the list, now has the above described
issues.

Is this a solaris limitation or a cvs limitation (there are about 2513
characters that make up the --allow-root argument string, excluding any
spaces)?

I could use different ports on the server to balance out the repositories
but WinCVS 1.3 doesn't retain port info inside the CVS admin subdirectory files
in the workares which causes problems for users who have to work out of
repos on different ports at the same time. (ie. instead of WinCVS 1.3
gathering all it needs from a workarea's CVS subdir to commit/update etc... it
uses the current port settings in the WinCVS preferences regardless of what the
workarea is currently being used this is quite annoying and confusing)...
if this issues has been fixed in WinCVS 1.3, please let me know.

Any help/insight/suggestions is appreciated. yes we only have one solaris
server to use, and yes we must have independent repositories..

Thanks,

Mark



__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/


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

Error

[Ford, Karen (MED, Contractor)]

I'm trying to tag a huge file (127MB) on Redhat and am getting the following
error:

> cvs [server aborted]: error writing to lock file /myfilename
> 
> There is no lock file in the repository, and the filesystem of the
> repository has 617 MB of space, and lots of inodes left.  There are no
> user quotas, and I've checked all the file and directory permissions.
> Previous tags to this file have worked, and tags on the other files in the
> repository worked.
> 
> Could the addition of the tag have put it over the file size limit?  If
> not, are there any other explanations?
> 


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