Re: Unix/Windows CR/LF Problems

2001-12-11 Thread Antonio Bemfica

I've had some of the same problems - I know now that line endings are
something to be very careful about (I enforce them with commitinfo now). 

Here are a few scripts I used to clean up my code (some files had lone LF
endings, of all thing...) - modify them to suit your needs. I initially
attempted to clean up the actual ,v files in the repository - in theory it
should work, but in my case it caused some problems - I ended up cleaning
up my working copy and commiting them back.

# this will print the filename of file with CR line endings (bad!)
perl -npi -e 'if (/\r(?!\n)/) { print STDOUT $ARGV\n; }' bad_newlines.txt
 
# this will pipe the filename of file with CR line endings to another perl
# script to replace them with NL
find ./medcon -name *.java -print | xargs \
perl -npi -e 'if (/\r(?!\n)/) { print STDOUT $ARGV\n; }' | uniq | \
xargs perl -npi -e 's/\r(?!\n)/\n/g'
 
# this will replace DOS line endings with UNIX - you could also use dos2unix
find ./medcon -name *.java -print | xargs \
perl -npi -e 's/\r\n/\n/g'

I have also attached commit_prep.pl, a file which I call from commitinfo:

DEFAULT /green/cvsuser/CVSROOT/commit_prep.pl -r

I got commit_prep.pl from this very list - the authors may have a more
recent version. 

Good luck

Antonio



On Tue, 11 Dec 2001, Robert Kirkbride wrote:

 I'm not sure if this is a WinCVS question or CVS in general.
 
 We've got some source files that are updated under Linux (1.11p1) and 
 under Windows.
 This seems to work ok but sometimes once when they are checked out 
 within Windows the lines are double spaced in Visual Studio (and it 
 produces a warning). In fact, they have a CR/CR/LF sequence instead of 
 just CR/LF or CR.
 
 Am I wrong in expected this to work ok?
 
 Rob Kirkbride



#!/usr/local/bin/perl
#
# Developed using perl, version 5.004_04 built for sun4-solaris
#
# Perl filter to handle pre-commit checking of files.  This program
# records the last directory where commits will be taking place for
# use by the log_accum.pl script.  It also checks the end of line
# termination for files with particular extensions to ensure there
# is no ctrl-M.  If any file with checked extensions
# has any line ending in ctrl-M, the entire commit is rejected.
#
# Add a line to your CVSROOT/commitinfo file something like:
# DEFAULT /cvs_repository/CVSROOT/commit_prep.pl -r
#
# Copyright 2001 David Martin http://www.scm-professionals.com
#
# Adapted from contrib directory sources by:
# David Hampton [EMAIL PROTECTED] and Greg A. Woods [EMAIL PROTECTED]
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
#
#   Configurable options
#

# Constants
#
$LAST_FILE = /tmp/#cvs.lastdir; # must match name in log_accum.pl
$ENTRIES   = CVS/Entries;

#$CrLog = %s is a text file and contains one or more ctrl-Ms.\nPlease remove ctrl-Ms 
and commit again!\n;
$CrLog = %s contains one or more ctrl-Ms.\nPlease remove ctrl-Ms and commit 
again!\n;

#   Subroutines
#

sub write_line {
local($filename, $line) = @_;
open(FILE, $filename) || die(Cannot open $filename, stopped);
print(FILE $line, \n);
close(FILE);
}

sub check_line_termination {
local($i);
local($filename, $cvsversion) = @_;

open(FILE, $filename) || return(0);

if ($debug != 0) {
print STDERR sprintf(file = %s, version = %d.\n, $filename, 
$cvsversion{$filename});
}

@all_lines = ();
for ($i = 0; FILE; $i++) {
chomp;
push(@all_lines, $_);
}

if (grep(/
$/, @all_lines)) {
print STDERR sprintf($CrLog, $filename);
return(1);
}

return(0);
}

#
#   Main Body   
#

$id = getpgrp();  # You *must* use a shell that does setpgrp()!

# Record the directory for later use by the log_accumulate stript.
#
$record_directory = 0;

# parse command line arguments
#
while (@ARGV) {
$arg = shift @ARGV;

if ($arg eq '-d') {
$debug = 1;
print STDERR Debug turned on...\n;
} elsif ($arg eq '-r') {
$record_directory = 1;
} else {
push(@files, $arg);
}
}

$directory = shift @files;

if ($debug != 0) {
print STDERR dir   - , $directory, \n;
print STDERR files - , join(:, @files), \n;
}

# Suck in the CVS/Entries file
#
open(ENTRIES, $ENTRIES) || die(Cannot open $ENTRIES.\n);
while (ENTRIES) {
local($filename, $version) = split('/', substr($_, 1));
$cvsversion{$filename} = $version;
}

# Now check each file name 

Re: giving up CVS

2001-09-17 Thread Antonio Bemfica

I am afraid you did not get my point. But then again, this seems to be a
common occurrence on this thread. 

A.

On Sat, 15 Sep 2001, Kaz Kylheku wrote:

 In article [EMAIL PROTECTED], Antonio Bemfica wrote:
 On Fri, 14 Sep 2001, Greg A. Woods wrote:
 
  [...]
 
 Whatever you say, buddy.
 
 Very intelligent there! Snip everything, and don't provide a reference
 to the message ID you are responding to.



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



Re: giving up CVS

2001-09-15 Thread Antonio Bemfica

On Fri, 14 Sep 2001, Greg A. Woods wrote:

 [...]

Whatever you say, buddy.

A.


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



Re: giving up CVS

2001-09-14 Thread Antonio Bemfica

From section 1.1 of Cederqvist:

1.1 What is CVS?

CVS is a version control system.

The concurrent part is a bonus (which does not apply to jpg files). 
Using CVS to record different versions of jpg files seems like a suitable
use of CVS to me. 

Antonio

On Fri, 14 Sep 2001, Alex Holst wrote:

 [...] I'm sure someone else will tell you this, but .jpg files are not
 suitable for concurrent editing so there is aboslutely no reason to put
 them in CVS space. [...]


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



Re: giving up CVS

2001-09-14 Thread Antonio Bemfica

The fact that a user versioning binary files will not be able to take full
advantage of CVS's power to parallelise software development does not mean
that CVS is of no value to him. CVS IS a versioning system and will track
changes to non-text files. If this is what the user wants, CVS is a
suitable tool for the job. 

A.

On Fri, 14 Sep 2001, Greg A. Woods wrote:

 [ On Friday, September 14, 2001 at 11:15:40 (-0400), Antonio Bemfica wrote: ]
  Subject: Re: giving up CVS
 
  From section 1.1 of Cederqvist:
  
  1.1 What is CVS?
  
  CVS is a version control system.
 
 Bogus attempts to mis-direct the reader like that need to be shot down
 quickly and completely.
 
 First off, CVS is, literally, the ``Concurrent Versions System''
 
 What this means, or at least as best described in a single phrase by the
 title of the paper describing its initial re-implementation as a C program:
 
   CVS II: Parallelizing Software Development
   Brian Berliner (Prisma, Inc.)
 
  The concurrent part is a bonus (which does not apply to jpg files). 
 
 No, the ``concurrent'' part is the central driving goal behind the
 creation and ongoing utility of CVS.  It is not just the first word in
 its full name, but rather what makes it possible for it to be of benefit
 in parallelisation of software development.
 
  Using CVS to record different versions of jpg files seems like a suitable
  use of CVS to me. 
 
 Using CVS to try to track changes to non-text files is a losing proposition,
 almost by definition.
 
 CVS is quite literally less useful for tracking changes to non-text
 files than RCS alone can ever be.
 
 -- 
   Greg A. Woods
 
 +1 416 218-0098  VE3TCP  [EMAIL PROTECTED] [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: Cleaning CRLFs from repository text files

2001-06-18 Thread Antonio Bemfica

Yes, I tried and it didn't work - which does not not mean it doesn't work
at all (it should work, some people say...), it just means that I gave up
after a while and just fixed the problem files on checked-out copies and
recommitted them (I only had so much time to throw at this glitch).

Antonio


On Mon, 18 Jun 2001 [EMAIL PROTECTED] wrote:

 
 We have some text files in a repository which contain DOS line endings,
 which were created on Windows and added to CVS from UNIX (via Samba, so
 no line conversion was done).  We also even have some files which
 contain mixed endings (CRLF and LF), depending on version.  I'd like to
 modify all the repository files so that history is retained and so that
 all have just UNIX line endings.  My first thought was to run 'tr -d
 '\r'' or dos2unix on the repository files themselves, but I'm wondering
 if this would result in some undesired side effect.
 
 Does anyone have experience doing this kind of surgery?
 
 Please also respond directly, since I'm not on the list.  Thanks!,
 --
 John Faith
 Lineo
 mailto:[EMAIL PROTECTED]
 
 
 
 
 ___
 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 server not translating line endings correctly

2001-04-05 Thread Antonio Bemfica

On Thu, 5 Apr 2001, David H. Thornley wrote:

[...]

 BTW, this will leave a bunch of ,v files in the repository with
 the ^Ms on them.  If I were to run some sort of ^M-removing
 script on them, should they be perfectly usable afterwards?
 Are there things to watch for that I wouldn't notice immediately
 after running it (I figure I back up and test immediately)?

I tried just that a few days ago (well, something very similar: somehow a
bunch of files actually were commited which had \r as end-of-line (not \r\n
as in DOS nor \n as in Unix) - this was due to a screwy editor plus jCVS). 

It did not work as well as I expected. I could checkout a file, but 'cvs
log' and cvsweb would fail - I assume there were other problems, but that
was enough to set off some alarm bells. I just restored the ,v file back
and ran the script on a checked out copy instead. 

A.


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



Re: [OT] bug tracking systems

2001-02-27 Thread Antonio Bemfica

Keystone is a very good issue tracking system. It is Open Source and uses
MySQL and PHP. You can check it out at http://keystone.whitepj.net/ -
WhitePJ recently acquired it from Stonekeep Consulting (www.stonekeep.com)

Antonio

On Tue, 27 Feb 2001, schmolle wrote:

 Hi list,
 
 [Robert Pollak] 'bug tracking system that provides some of bugzilla's
 functionality' __ What I like most about bugzilla is the ability to
 attach files (patches, test examples, log files) to a bug entry. 
 
 A tip I would like to share:
 
 At my company, we use Rational ClearQuest for one of our clients (avoid
 the tool; you can hire a whole developer for a year for what it costs)
 and we had an issue with a client logging bugs that would -- for good
 measure -- have to include log files. The problem was that those files
 can easily balloon into 150MB / day. [...]


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



Re: Partial unsubscribe?

2000-09-22 Thread Antonio Bemfica

I use procmail to filter my messages and eliminate duplicates. I found
that mailing list administrators often cannot respond as fast as users
would like to problems such as the one info-cvs is having now (assuming
this problem is with the list, not e-groups as suggested).

A.

On Fri, 22 Sep 2000, Ernest Schwaegerl wrote:

 Is there any way that I can unsubscribe from 2/3 of this listserv? Then I
 would (theoretically) only get ONE copy of each of these messages.
 
 Seriously, is anyone looking at this issue? Is it an issue?
 
 Ernest J Schwaegerl
 
 "I drank WHAT?  - Socrates 
 
 Ernest J Schwaegerl
 Software QA
 
 Grundig Digital Systems
 2550 N. First St
 4th floor
 San Jose, CA 95131
 
 Phone 408-456-8438
 FAX   408-456-8401
 [EMAIL PROTECTED]
 
 

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



CVS versus MKS (or should I avoid moving to MKS?)

2000-09-12 Thread Antonio Bemfica

Hello

I currently use CVS for our projects - we have 9 modules, about 9300
files, close to 80Mbytes in total (mostly .jsp and .java files).  We don't
do much in-house development, but quite a bit of bug fixing and minor
improvements.

Most of the new development is done offsite for us - the code gets shipped
to me and I merge the branch, etc. The CM experts in the company that does
the offsite development for us are starting to recommend (and push) MKS as
a "solution" which according to them would allow for better concurrent
development and all kinds of extra good things. The offsite developers now
use Visual Source Safe and would give it up in favour of MKS.

I know CVS allows for remote access and would be happy to keep using it. 
However, I will need to provide some reasons to my boss as to why we
should ignore the good advice of the CM specialists. In fact, should I
stick to CVS? I like CVS, but if MKS is truly a better tool, and the size
and scope of our projects warrant it, perhaps we should adopt it? Should
we keep CVS while they use MKS? 

Anyways, to end this long note, I would appreciate any comments you all
may have about my situation.

Thanks in advance

Antonio