RE: questions on tracking 3rd party sources

2000-07-26 Thread Stephen L Arnold

(oops, I meant to send this to the list as well...)

Hey, thanks a bunch guys.  I tried it and it worked 8-)

I actually had a module defined for the RSDS code (but thanks for
pointing that out; it made me update my procedures...)

Thanks again, Steve


Stephen L. ArnoldSenior Systems Engineer
VAFB IVV Activityemail:  [EMAIL PROTECTED]
ENSCO Inc.www:  http://www.ensco.com
P.O. Box 5488voice: 805.606.8838
Vandenberg AFB, CA  93437  fax: 805.734.4779
 
with Std.Disclaimer;  use Std.Disclaimer;



 -Original Message-
 From: Larry Jones [mailto:[EMAIL PROTECTED]]
 Sent: Monday, July 24, 2000 1:44 PM
 To: [EMAIL PROTECTED]
 Subject: Re: questions on tracking 3rd party sources
 
 
 Stephen L Arnold writes:
  
  I'm not sure I get it yet.  Do I need to do the above 
 "checkout" command
  before or after I import the new source tree?
 
 After.
 
  So the sequence of operations would be:
  
  $ cvs import -m "Import of FSF v. 0.04" fsf/wdiff FSF_DIST 
 WDIFF_0_04
  $ cvs checkout fsf/wdiff
 
 This checkout isn't necessary.
 
  $ tar xfz wdiff-0.05.tar.gz
  $ cd wdiff-0.05
  $ cvs import -m "Import of FSF v. 0.05" fsf/wdiff FSF_DIST 
 WDIFF_0_05
  
  then
  
  $ cvs checkout -jWDIFF_0_04 -jWDIFF_0_05 wdiff
 
 Given the above, that would have to be:
 
   $ cvs checkout -jWDIFF_0_04 -jWDIFF_0_05 fsf/wdiff
 
 and you'd need to follow it with:
 
   $ cd fsf/wdiff
   $ cvs ci -m'merge changes'
 
 -Larry Jones
 
 I'm getting disillusioned with these New Years. -- Calvin
 




questions on tracking 3rd party sources

2000-07-24 Thread Stephen L Arnold

Howdy:

I've been playing around with CVS for a little while, and I'd like to get started 
using it at work (mostly configuring external code we get in for review).  I've gone 
through much of the manual, as well as a few other docs, and I still have some 
questions.

In the section on Tracking Third-Party Sources (in the main CVS manual), it talks 
about importing code for the first time like this:

$ cd wdiff-0.04
$ cvs import -m "Import of FSF v. 0.04" fsf/wdiff FSF_DIST WDIFF_0_04

where the last two arguments above are the Vendor_tag and Release_tag.  Then, to 
update the repository to the latest vendor source, do this:

$ tar xfz wdiff-0.05.tar.gz
$ cd wdiff-0.05
$ cvs import -m "Import of FSF v. 0.05" fsf/wdiff FSF_DIST WDIFF_0_05

I assume this pre-supposes that the new version (wdiff-0.05) has the same directory 
structure, and the same set of (modified) source files as the previous version.  What 
happens if the organization of the source tree was changed?  How much can CVS do on 
it's own, or do I basically have to analyze all the changes beforehand and do a whole 
slew of "cvs add" "cvs rm" etc?  (I was hoping CVS would help with this part).

A couple sections farther in the manual is one called Multiple Vendor Branches, which 
uses the -b (branch tag) to distinguish between two different branches of the same 
code:

$ cvs import dir RED RED_1-0
$ cvs import -b 1.1.3 dir BLUE BLUE_1-5

Would this be a better approach for me?  What are the implications if I do it this way?

I'm still learning about tags, revisions, branches, etc, so please phrase your answers 
in the form a dummy like me can understand :)

Any suggestions from the more experienced would be greatly appreciated.  Thanks in 
advance, Steve Arnold

************
Stephen L. ArnoldSenior Systems Engineer
VAFB IVV Activityemail:  [EMAIL PROTECTED]
ENSCO Inc.www:  http://www.ensco.com
P.O. Box 5488voice: 805.606.8838
Vandenberg AFB, CA  93437  fax: 805.734.4779
 
with Std.Disclaimer;  use Std.Disclaimer;

 




subscribing to cvs-info

2000-07-19 Thread Stephen L Arnold

From Pacal Molli's CVS Bubbles site:

http://www.loria.fr/cgi-bin/molli/wilma.cgi/misc.847278364.html

Please note that you must send mail to [EMAIL PROTECTED] with that text 
to unsubscribe : unsubscribe info-cvs
"your-email-address-here" 

URL: mailto:[EMAIL PROTECTED] 

********
Stephen L. ArnoldSenior Systems Engineer
VAFB IVV Activityemail:  [EMAIL PROTECTED]
ENSCO Inc.www:  http://www.ensco.com
P.O. Box 5488voice: 805.606.8838
Vandenberg AFB, CA  93437  fax: 805.734.4779
 
with Std.Disclaimer;  use Std.Disclaimer;

 




RE: Unix to Dos filtering

2000-03-08 Thread Stephen L Arnold

 -Original Message-
 From: Tony Hoyle [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, March 08, 2000 4:05 AM
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: Re: Unix to Dos filtering
 
 
 Stephen L Arnold wrote:
 
  Wrong.  I distinctly remember the samba guys (Allison  
 Tridgell) saying they didn't want samba to attempt any such 
 conversion.  From the samba docs:
 
 Hmm...  There is a FAQ (must dig it out if I can find it) 
 that specifically mentions that smbfs honours the 'conv=' options
 line FAT does.
[snip]

smbfs and samba are two different (but related) things (and are typically merged in 
most people's minds).  smbfs is the smb filesystem that linux/unix/whatever needs in 
order to mount smb shares exported from other hosts.  Samba is a pair of daemons (smbd 
and nmbd) that provide a non-windoze host with the ability to export smb shares to 
other hosts on the network.  Samba also does browse-master, domain logins, some domain 
control stuff, smb print services, etc.  I believe you are right about smbfs honoring 
the 'conv=' stuff, however, you didn't say "smbfs" you said "samba" (so I had to chime 
in ;)

Steve
with Std.Disclaimer;  use Std.Disclaimer;




RE: Unix to Dos filtering

2000-03-07 Thread Stephen L Arnold

 -Original Message-
 From: Tony Hoyle [mailto:[EMAIL PROTECTED]]
 Sent: Monday, March 06, 2000 9:33 AM
 Subject: Re: Unix to Dos filtering

[snip]
 Much of the same caveats exist re: sharing over samba as 
 sharing over NFS, only worse (samba has this habit of attempting
 to convert text files itself unless you stop it...)

Wrong.  I distinctly remember the samba guys (Allison  Tridgell) saying they didn't 
want samba to attempt any such conversion.  From the samba docs:

!==
!== CRLF-LF-Conversions.txt for Samba release 2.0.5a 22 Jul 1999
!==
We get many requests for CRLF/LF format conversion handling by samba.
The problem is that there is no clean way to determine which files
should / could be converted and which MUST not be.

Since Unix and DOS/Windows uses alike will use .txt to represent a
file containing ASCII text we can not reliably use the file extension.
The same applies to the .doc extension.

Samba operates around the premise that we should leave all files unchanged.
By not implementing CRLF/LF conversions we can not be guilty of damaging
anyone's files.

When someone comes along with a sound implementation that guarantees file
integrity we will jump at the opportunity to implement this feature. Until
such time there is no prospect for action on this topic.
!==
!== end CRLF-LF-Conversions.txt
!==

You may want to re-think your understanding of samba, et al.

Steve



update: pserver/cvsweb access problem

2000-03-02 Thread Stephen L Arnold

Howdy (again):

I tried the env trick in inetd.conf, but it doesn't seem to help.  
I tried:

env --unset=home
env -
env home=

The first one gives this error:

 cvs login (Logging in to arnold@shiva)
 cvs [login aborted]: recv() from server shiva: Connection reset by
 peer
 
 *CVS exited normally with code 1*

while the last two give this error:

 cvs login  (Logging in to arnold@shiva)
 cvs [login aborted]: unrecognized auth response from shiva: CVS commands are:
 
 *CVS exited normally with code 1*

CVS-web still barfs with the same error as before.

I just found one of the messages on egroups about my first post, 
and it seems to me (from my layman's perspective) that CVS should 
*not* have to be patched (or kluged) to deal with this, rather 
inetd should behave correctly.  Do the RedHat weenies know about 
this?  What was their response?  Why doesn't the env trick work for 
me?

Thanks again, Steve

**
Stephen L Arnold  http://www.rain.org/~sarnold
with Std.Disclaimer;  use Std.Disclaimer;
**