Re: Showing diff in commit message editor

[Thomas S. Urban]

On Fri, Jan 09, 2004 at 16:34:36, Cameron McCormack spake thusly:
> When I "cvs commit" I often forget exactly what I've changed in my
> files.  Is there a way to get cvs to display in the commit message file,
> underneath the "modified files/added files/deleted files" comment, the
> diffs I am about to commit?

I use a cvscommit alias/function for csh/zsh, then set the CVSEDITOR
environment variable to open the cvstemp.diff file in addition to the
log message (setting for vim shown):

csh:
  alias cvscommit 'cvs diff \!* > cvstemp.diff || cvs commit \!*; rm cvstemp.diff'
  setenv CVSEDITOR 'vim -X -o cvstemp.diff'

zsh (sh too?):
  cvscommit () {
cvs diff $* > cvstemp.diff || cvs commit $*
rm -f cvstemp.diff
  }
  CVSEDITOR='vim -X -o cvstemp.diff'
  export CVSEDITOR

When I do cvscommit [optional options/files/dirs], this gives me a vim
editor with two vim windows - one with the diffs, one with the log
message to edit.  The -X for vim tells it not connect to the X server -
a speedup for working remotely.

Scott


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

Re: Command-line multi-line messages for commit

[Thomas S. Urban]

On Sun, Jun 08, 2003 at 13:07:59 -0400, Greg A. Woods sent 1.5K bytes:
> [ On , June 8, 2003 at 10:46:45 (+0300), Stephen Biggs wrote: ]
> > Subject: Re: Command-line multi-line messages for commit
> >
> > Actually, your method sounds to me much more painful because I have to
> > learn how to use sed to do this and run and test the wrapper script over
> > and over again until I debug it due to my limited expertise in coding
> > shell scripts, living with bogus messages in a junk repository until I
> > get it right.  My way is quicker and much simpler for me as long as I
> > remember to put the quotes right.
> 
> Why the heck don't you use a proper command shell and then you can just
> type multi-line comments right there on the command-line!?!?!?
> 
>   cvs commit -m 'first line
>   second line
>   third line' filname.c
> 
> I.e. DO NOT use 'csh'.  It is the source of your problems.  Use a POSIX
> compatible shell instead (e.g. sh or ksh or one of their close variants).

Properness and POSIX compliance aside, csh (and tcsh)  handle this fine,
although the method looks a little different:

% cvs commit -m 'first line \
? second line \
? third line' filename.c

'%' and '?' are prompts.  



HTH
Scott


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

Re: anyone got a copy of vss2cvs.pl?

[Thomas S. Urban]

I don't have the original version, but I can give you my version - it
has some modifications handle:
  - directory recursion
  - ignore certain extensions
  - ignore binary files
  - import shared files once - this is a big time saver, though you'll
have to work with your CVS repository directly after the fact to
deal with where the shared files ended up and all the files that
"point" to them.  This is the kind of thing you have to do anyway
when importing VSS repositories to CVS
  - change author names in massage step

Most of these changes are explained in the file vss2cvs.pl.  Let me know
if you have questions.

Files:

 README.txt - original readme
 listshares.pl  - original share listing utility
 vss2cvs.pl - my modified import script
 massagecomments.pl - original post processing script
 mymassagecomments.pl   - my version of above - does author mangling
 findauthors.pl - my utility to find author names
 countrevisions.pl  - my import stats utility

On Wed, Nov 27, 2002 at 16:28:24 -0500, James Manning sent 0.5K bytes:
> I'm trying to track down a copy of the vss2cvs perl script.  It
> normally lived at http://www.laine.org:8080/cvs/vss2cvs/ but that
> server has been dead for at least a couple weeks now, so I'm asking
> around to see if anyone has a copy.
> 
> Thanks!
> 
> James
> -- 
> James Manning 
> GPG Key fingerprint = B913 2FBD 14A9 CE18 B2B7  9C8E A0BF B026 EEBB F6E4
> 
> 
> ___
> Info-cvs mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/info-cvs

-- 
The "cutting edge" is getting rather dull.
-- Andy Purshottam



vss2cvs.tar.gz
Description: GNU Zip compressed data

Re: Merging in CVS

['Thomas S. Urban']

I'm curious if the feedback about how "CVS handles merges poorly" is
about the automatic merge action or the way conflicts are presented? I'm
guessing the latter.  If you'll listen to what people here are saying, I
think you'll find the answer to your question:

  - CVS and clear case both do the same things for merging (automatic if
possible, require user intervention if not)

  - if editing files to deal with conflicts is distasteful to you or
your developers, conflict resolution tools exist or can easily be
written that should please your editor-phobic developers.  I'm sure
if you look you can find a tool that matches the capabilities of the
clearcase one.

  - using this and other tools in conjunction with CVS is a matter of
policy and/or administration - it is your responsibility to show or
tell people how to use the tools, or provides scripts or commands or
other automation so it happens as appropriate


On Fri, Nov 22, 2002 at 13:53:58 -0500, MacMunn, Robert sent 5.1K bytes:
> We have 3 CM tools within the whole comapny.  CVS, Perforce, and Clearcase.
> 
> Management wants to go with 1 tool.  They feel Clearcase is too expensive,
> and it can be.  I am a Clearcase guy, but know the cost.  So, Perforce seems
> limited, CVS seems to be able to handle all that we need.  I just need to
> make sure that there aren't any gotcha's.  
> 
> >From the feedback I am getting from other CVS users is that CVS handles
> merges poorly.  I am not here to start an arguement on which is the better
> CM tool.  I am not closed minded to think that because I know Clearcase,
> that it is the best tool.  I am trying to find out where we may have
> problems with release engineering and developers.  The graphical merge tool
> Clearacse has saves a lot of time, and it is part of Clearcase.  The cost of
> Clearcase is just too astronomical now  and like I said CVS seems to have
> all that we need.  I am just trying to figure out what we gain and what we
> lose.
> 
> -Original Message-
> From: 'Thomas S. Urban' [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 22, 2002 1:39 PM
> To: MacMunn, Robert
> Cc: [EMAIL PROTECTED]
> Subject: Re: Merging in CVS
> 
> 
> So use Clearcase if it provides something you can't live without.  I'm
> only trying to point out that logically, the operations are the same
> (the timing may be a little different), e.g:
> 
>   1 You request an update of local file to newest version in repository
>   2 CVS will merge new version and local changes (if any) automatically,
> (if possible)
>   3 If automatic merge is not possible, CVS forces user to *manually*
> resolve conflicts
> 
> If you can show my how clearcase behaves differently than this
> *logically*, then maybe you've got a point (and maybe I'll start using
> clearcase since it would then have the ability to read my mind).
> 
> Everthing else is just interfaces and easy of use, both of which are
> qualities easy to remedy through toolsmithing, IMO.
> 
> 
> On Fri, Nov 22, 2002 at 13:28:02 -0500, MacMunn, Robert sent 3.0K bytes:
> > It isn't a slick interface. In Clearcase it is the merge tool itself that
> > gives you the ability to deal with the conflicts easily.
> > 
> > -Original Message-
> > From: 'Thomas S. Urban' [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, November 22, 2002 1:27 PM
> > To: MacMunn, Robert
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: Merging in CVS
> > 
> > 
> > On Fri, Nov 22, 2002 at 13:17:12 -0500, MacMunn, Robert sent 1.7K bytes:
> > > Not at all.  In Clearcase you have a graphical interface where the
> > conflicts
> > > can be taken care of as the merge happens.  No manual editting of files.
> > 
> > A nice tool with a graphical interface is still a manual tool.  It may
> > be easier to use than a simple text editor (but why would you use a
> > simple text editor?), but both process are manual versus automatic.  
> > Perhaps the time the manual work happens is significant, I don't know,
> > but it still happens.
> > 
> > Graphical interfaces for dealing with the conflict markers CVS produces
> > probably exist, either with one of the many GUI clients, or with emacs.
> > The vim plugin I use highlights them specially.  If I cared, I could
> > write easy vim functions that would take one version or the other for
> > each conflict.  But it rarely comes up in our usage (i.e. including good
> > communication), so I don't care all that much about slick interfaces to
> > conflict resolution.
> > 
> > > 
> > > -Original Message-

Re: Merging in CVS

['Thomas S. Urban']

So use Clearcase if it provides something you can't live without.  I'm
only trying to point out that logically, the operations are the same
(the timing may be a little different), e.g:

  1 You request an update of local file to newest version in repository
  2 CVS will merge new version and local changes (if any) automatically,
(if possible)
  3 If automatic merge is not possible, CVS forces user to *manually*
resolve conflicts

If you can show my how clearcase behaves differently than this
*logically*, then maybe you've got a point (and maybe I'll start using
clearcase since it would then have the ability to read my mind).

Everthing else is just interfaces and easy of use, both of which are
qualities easy to remedy through toolsmithing, IMO.


On Fri, Nov 22, 2002 at 13:28:02 -0500, MacMunn, Robert sent 3.0K bytes:
> It isn't a slick interface. In Clearcase it is the merge tool itself that
> gives you the ability to deal with the conflicts easily.
> 
> -Original Message-
> From: 'Thomas S. Urban' [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 22, 2002 1:27 PM
> To: MacMunn, Robert
> Cc: [EMAIL PROTECTED]
> Subject: Re: Merging in CVS
> 
> 
> On Fri, Nov 22, 2002 at 13:17:12 -0500, MacMunn, Robert sent 1.7K bytes:
> > Not at all.  In Clearcase you have a graphical interface where the
> conflicts
> > can be taken care of as the merge happens.  No manual editting of files.
> 
> A nice tool with a graphical interface is still a manual tool.  It may
> be easier to use than a simple text editor (but why would you use a
> simple text editor?), but both process are manual versus automatic.  
> Perhaps the time the manual work happens is significant, I don't know,
> but it still happens.
> 
> Graphical interfaces for dealing with the conflict markers CVS produces
> probably exist, either with one of the many GUI clients, or with emacs.
> The vim plugin I use highlights them specially.  If I cared, I could
> write easy vim functions that would take one version or the other for
> each conflict.  But it rarely comes up in our usage (i.e. including good
> communication), so I don't care all that much about slick interfaces to
> conflict resolution.
> 
> > 
> > -Original Message-
> > From: Thomas S. Urban [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, November 22, 2002 1:16 PM
> > To: MacMunn, Robert
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: Merging in CVS
> > 
> > 
> > On Fri, Nov 22, 2002 at 12:23:56 -0500, MacMunn, Robert sent 0.9K bytes:
> > > Thanks.  Looks like merges must be difficult in CVS.  A lot of manual
> > work.
> > 
> > Most of the time, merges happen automatically.  Manual intervention is
> > only required when they can't happen automatically. Conflicts always
> > take (some amount) of a manual work. Merges never do.  I don't see how
> > you can get around this fact in any system, short of exclusivity.
> > 
> > Looks like you may be confused by terminology. RTFM.
> > 
> > HTH
> > Scott
> > 
> > 
> > > 
> > > -Original Message-
> > > From: Kaz Kylheku [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, November 22, 2002 12:18 PM
> > > To: MacMunn, Robert
> > > Cc: [EMAIL PROTECTED]
> > > Subject: Re: Merging in CVS
> > > 
> > > 
> > > On Fri, 22 Nov 2002, MacMunn, Robert wrote:
> > > 
> > > > I am new to CVS.  I am testing out merging.
> > > > 
> > > > When I merged 2 files I got extra lines teling me where the merged
> lines
> > > > where.
> > > > Is there any way around this ?
> > > > 
> > > > Ex.
> > > > The <<<<<<< and >>>>>  delimit the merged lines.
> > > 
> > > No, they delimit conflicts. You can't get around conflicts. You must
> > > resolve them when they occur, and you can't prevent them from occuring,
> > > unless people working independently magically stay out of each other's
> > > way.
> > > 
> > > RTFM!
> > > 
> > > 
> > > ___
> > > Info-cvs mailing list
> > > [EMAIL PROTECTED]
> > > http://mail.gnu.org/mailman/listinfo/info-cvs
> 
> -- 
> Stupidity is its own reward.

-- 
Building translators is good clean fun.
-- T. Cheatham


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

Re: Merging in CVS

[Thomas S. Urban]

On Fri, Nov 22, 2002 at 12:23:56 -0500, MacMunn, Robert sent 0.9K bytes:
> Thanks.  Looks like merges must be difficult in CVS.  A lot of manual work.

Most of the time, merges happen automatically.  Manual intervention is
only required when they can't happen automatically. Conflicts always
take (some amount) of a manual work. Merges never do.  I don't see how
you can get around this fact in any system, short of exclusivity.

Looks like you may be confused by terminology. RTFM.

HTH
Scott


> 
> -Original Message-
> From: Kaz Kylheku [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 22, 2002 12:18 PM
> To: MacMunn, Robert
> Cc: [EMAIL PROTECTED]
> Subject: Re: Merging in CVS
> 
> 
> On Fri, 22 Nov 2002, MacMunn, Robert wrote:
> 
> > I am new to CVS.  I am testing out merging.
> > 
> > When I merged 2 files I got extra lines teling me where the merged lines
> > where.
> > Is there any way around this ?
> > 
> > Ex.
> > The <<< and >  delimit the merged lines.
> 
> No, they delimit conflicts. You can't get around conflicts. You must
> resolve them when they occur, and you can't prevent them from occuring,
> unless people working independently magically stay out of each other's
> way.
> 
> RTFM!
> 
> 
> ___
> 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: Merging in CVS

['Thomas S. Urban']

On Fri, Nov 22, 2002 at 13:17:12 -0500, MacMunn, Robert sent 1.7K bytes:
> Not at all.  In Clearcase you have a graphical interface where the conflicts
> can be taken care of as the merge happens.  No manual editting of files.

A nice tool with a graphical interface is still a manual tool.  It may
be easier to use than a simple text editor (but why would you use a
simple text editor?), but both process are manual versus automatic.  
Perhaps the time the manual work happens is significant, I don't know,
but it still happens.

Graphical interfaces for dealing with the conflict markers CVS produces
probably exist, either with one of the many GUI clients, or with emacs.
The vim plugin I use highlights them specially.  If I cared, I could
write easy vim functions that would take one version or the other for
each conflict.  But it rarely comes up in our usage (i.e. including good
communication), so I don't care all that much about slick interfaces to
conflict resolution.

> 
> -Original Message-----
> From: Thomas S. Urban [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 22, 2002 1:16 PM
> To: MacMunn, Robert
> Cc: [EMAIL PROTECTED]
> Subject: Re: Merging in CVS
> 
> 
> On Fri, Nov 22, 2002 at 12:23:56 -0500, MacMunn, Robert sent 0.9K bytes:
> > Thanks.  Looks like merges must be difficult in CVS.  A lot of manual
> work.
> 
> Most of the time, merges happen automatically.  Manual intervention is
> only required when they can't happen automatically. Conflicts always
> take (some amount) of a manual work. Merges never do.  I don't see how
> you can get around this fact in any system, short of exclusivity.
> 
> Looks like you may be confused by terminology. RTFM.
> 
> HTH
> Scott
> 
> 
> > 
> > -Original Message-
> > From: Kaz Kylheku [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, November 22, 2002 12:18 PM
> > To: MacMunn, Robert
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: Merging in CVS
> > 
> > 
> > On Fri, 22 Nov 2002, MacMunn, Robert wrote:
> > 
> > > I am new to CVS.  I am testing out merging.
> > > 
> > > When I merged 2 files I got extra lines teling me where the merged lines
> > > where.
> > > Is there any way around this ?
> > > 
> > > Ex.
> > > The <<<<<<< and >>>>>  delimit the merged lines.
> > 
> > No, they delimit conflicts. You can't get around conflicts. You must
> > resolve them when they occur, and you can't prevent them from occuring,
> > unless people working independently magically stay out of each other's
> > way.
> > 
> > RTFM!
> > 
> > 
> > ___
> > Info-cvs mailing list
> > [EMAIL PROTECTED]
> > http://mail.gnu.org/mailman/listinfo/info-cvs

-- 
Stupidity is its own reward.


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

Re: CVS notifications with meaningfull subject

[Thomas S. Urban]

On Tue, Aug 27, 2002 at 07:02:44 +0200, Piet Verhoeve sent 0.5K bytes:
> We are successfully using the CVS watch option for monitoring common
> modules. In order to reduce the amount of emails the user has to open, I
> would like to send out notifications that have a variable subject line (e.g.
> the username or filename) instead of sending out notifications with the
> information stored only in the body of the mail.
> 
> Any ideas ?

It's pretty easy with a script called by the notify mechanism, here are
some bits pruned out of the script I use (below).  Something to start
with - further refinement is an exercise in perl (or whatever language),
not really a CVS question.

-- begin cvsnotify.pl --
#!/usr/bin/perl

$CVSROOT = '/YOURCVSROOT';   # config

$watcher_address = shift @ARGV;  # watch is single arg

@cvs_input = <>; # parse notify info passed in on stdin

chomp @cvs_input;# remove newlines

shift @cvs_input;# skip a line
shift @cvs_input;# skip a line

$module = shift @cvs_input;  # better place to get module
$module =~ s/Triggered (\w+) watch on $CVSROOT\///;

$file =~ s/^$module //;
$line = shift @cvs_input;# changed by - should be the same
($nop, $changer) = split (' ',$line);# as the email sender

$rlog_file = $CVSROOT . '/' . $module . '/' . $file . ',v';

# then do something with this info, e.g., put the changer, file, and
# module in the subject line:
open (MAIL, "| mail -s '$changer changed $file in $module' $watcher_address");
print MAIL "interesting things can be done by looking at the rcs file\n";
close MAILINP;

-- end cvsnotify.pl --

Make sure CVS is set up to use the script, for starters:

-- begin CVSROOT/notify --
ALL /PATHTO/cvsnotify.pl %s
-- end CVSROOT/notify --

-- 
Nobody knows the trouble I've been.


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

Re: Moving CVS repository

[Thomas S. Urban]

On Fri, May 03, 2002 at 16:14:14 -0400, Greg A. Woods sent 0.8K bytes:
> [ On Friday, May 3, 2002 at 13:30:04 (-0400), Larry Jones wrote: ]
> > Subject: Re: Moving CVS repository
> >
> > Greg A. Woods writes:
> > > 
> > > there are zillions of basically unsolvable issues which arise if there's
> > > any use of *info files.
> > 
> > The way CVS handles a directory tree with multiple CVSROOTs is by
> > running the command once for each root with just the directories that
> > have that root.  As far as I can tell, the *info files work just like
> > you'd expect in that scenario.  Can you provide an explicit example?
> 
> One word:  policy.

One word: clarification?


Scott

-- 
Simon's Law:
Everything put together falls apart sooner or later.

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

Re: keeping one's personal dotfiles under CVS

[Thomas S. Urban]

On Fri, Apr 19, 2002 at 11:49:38 +0200, Louis-David Mitterrand sent 0.7K bytes:
> I was wondering what strategies do CVS gurus use to manage their
> personal collection of dotfiles. We all a favorite .vimrc, .exrc,
> .muttrc, ~/.w3m/bookmarks.html, etc. The problem is keeping them in sync
> on all the machines we use. CVS seems like a nice tool for that.
> 
> How would you go about keeping a repository of personal dotfiles?

As someone else replied, rsync might be better.  I do use CVS for this
purpose though.  It may be overkill, but it works.  I have a module
called private/scottu that I checkout to ~/common.  In there, I have all
my resource files layed out - in general with leading '.' removed, and
then I have a couple makefiles that create links to these files with the
appropriate name in my home dir or subdirs.  E.G. it makes these links

~/.vimrc -> ~/common/vimrc
~/.vim   -> ~/common/vim/
~/.cshrc -> ~/common/cshrc
~/.csh   -> ~/common/csh/
~/.mutt  -> ~/common/mutt
etc.

HTH

-- 
It's currently a problem of access to gigabits through punybaud.
-- J. C. R. Licklider

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

Re: PROPOSAL: Addressing the list's spam issue: was: [GB2312] ±ÜÃâåeÎóµÄÍâÙQÐÐäN·½Ê

[Thomas S. Urban]

in_favor++;

> 


-- 
Maybe Computer Science should be in the College of Theology.
-- R. S. Barton

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

Re: vss2cvs.pl Maintenance?

[Thomas S. Urban]

On Tue, Apr 02, 2002 at 07:02:43 -0500, Kevin Hendrickson sent 0.9K bytes:
> I'm new to the list and was wondering if vss2cvs is being maintained
> anywhere other than http://www.laine.org? I cannot seem to get to that
> site anymore. I'm interested in posting a patch I've made to the latest
> version that allows it to work on Japanese systems running VSS. It fixes a
> problem with parse_user_and_timestamp which only handled US and European
> time formats and lacked the Japanese words to parse with. Any ideas where
> I should post the patch? :-)

I have my own version that I patched to support features I wanted
(controlling what files are imported, handling shared files in a
semi-smart way, and some other stuff).  I provided my changed to Laine,
but never heard back from him.  Since www.laine.org has been down, I've
been contacted several times for the scripts.  Given that situation, I
am considering putting together a site for my modified versions of the
scripts. You can send your patches to me and I'll try to incorporate
them into my stuff.

If someone else wants to take over maintenance, or if Laine would like
to speak up, I'm ok with that too.

Scott


-- 
statistics, n.:
A system for expressing your political prejudices in convincing
scientific guise.

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

Re: how to check contents of file running commitinfo script

[Thomas S. Urban]

On Sat, Mar 23, 2002 at 00:40:59 -, brianpdoyle sent 0.8K bytes:
> I'm sure that I'm missing something obvious here, but I'm wanting to 
> make sure that before any Java file has the correct legal header in 
> the file before committing the file to the repository.  I see how I 
> get the name of the file to the script handed off by commitinfo, but 
> how do I get the contents of the file that the user is trying to 
> submit?  The ",v" file is there, but does it contain the user's 
> changes to that file, if it hasn't been committed yet?  Does CVS 
> store this file to a temp directory or something?  There's no info 
> about getting the contents of the pre-committed file in the 
> documentation.  Thanks in advance

Just open the file passed in as the 2nd - nth arguments to the script -
the first argument is the module.  I believe the script is run from the
module directory in the repository.  If you were using perl, you would
do something like this:

$module_dir = shift @ARGV;

foreach $file (@ARGV)
{
open (FILE, "$file");

}

HTH
Scott

-- 
All most people want is a little more than they'll ever get.

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

Re: cvs commitinfo - remote access issues - enforced code beautification

[Thomas S. Urban]

On Thu, Mar 21, 2002 at 12:20:39 -0500, Larry Jones sent 0.5K bytes:
> Thomas S. Urban writes:
> > 
> > It certainly does work for changes made with the commitinfo script - an
> > undocumented feature, perhaps.
> 
> Only if there are RCS keywords in the file that also change as a result
> of the checkin.  Like I said, using RCS keywords to get under-the-table
> changes made on the server back to the client is a kludge that shouldn't
> be depended on to keep working in the future.

Yeah, I understand that keywords expansion is required for my kludge to
work, and that what I am doing is a definitely a kludge.  If this
undocumented feature is ever removed, I will have to reevaluate what I'm
doing.  If this ever does change, I would request that in addition to
fixing what information is sent back to the client (diff versus whole
file), the developers should also remove the capability to modify the
file that gets checked in - give the commitinfo script a temporary copy
of each file that isn't used to modify the rcs file.  Either that or
properly support and docuemnt the feature ;).

Scott


-- 
The English have no respect for their language, and will not teach
their children to speak it.
-- G. B. Shaw

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

Re: cvs commitinfo - remote access issues - enforced code beautification

[Thomas S. Urban]

On Thu, Mar 21, 2002 at 08:15:03 -0800, Noel Yap sent 0.9K bytes:
> --- Larry Jones <[EMAIL PROTECTED]> wrote:
> > No, commit does a checkout to expand keywords -- see
> > checkin.c starting
> > at the comment that says:
> > 
> > /* The checkin succeeded.  If checking the file out
> > again would not cause any changes, we are done.
> > Otherwise, we need to check out the file, which will
> > change the modification time of the file.
> > 
> > The only way checking out the file could cause any
> > changes is if the file contains RCS keywords.  So we if
> > we are not expanding RCS keywords, we are done.  */
> 
> Thanks for clearing this up.  This comment also
> indicates that the checkout is specific to updating
> RCS keywords so it wouldn't work for changes made by a
> commitinfo script.

It certainly does work for changes made with the commitinfo script - an
undocumented feature, perhaps.

Scott

-- 
People say I live in my own little fantasy world... well, at least they
*know* me there!
-- D.L. Roth

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

Re: cvs commitinfo - remote access issues - enforced code beautification

['Thomas S. Urban']

On Thu, Mar 21, 2002 at 09:15:00 +0530, Shubhabrata Sengupta sent 3.1K bytes:
> I think that the server "writes back" the files to the client. Isn't
> this the way keywords are expanded on the client side once the checkin
> is through?

This is true.

Greg, I'm replying to your stuff here, since your message never appeared
on my server.

> Greg A. Woods apparently wrote:
>> Hmmm but that can happen only on the server.  If you modify a file
>> unbeknownst to the user doing a commit from a remote client then you've
>> suddenly changed what he or she is committing without necessarily
>> telling them.

My experience is that the client will get all my automated changes as
long as keyword expansion will be done on the file.  Looking at the
client/server debug output files, it appears that the entire file is
sent back to the client even though perhaps a diff would do.  This is
perhaps a bug in CVS that I am taking advantage of.  CVS changes pretty
slow, but if this ever does, I'll have to reevaluate what I'm doing.



>> Commitinfo can be used to reject a commit, but it should not ever be
>> used to change a file, and especially not to then allow the changed file
>> to be committed.  Users change files and then commit their changes to a
>> change tracking tool.  The change tracking tool should not itself ever
>> make any changes.

Well, tht change tracking tool already makes changes (keyword expansion)
;).  I agree that having the tool make automated changes is not the best
idea in theory.  But I don't live in a perfect world, and what I'm
doing fixes problems I am unable to solve through policy or discipline; 
not once since I've used my automation has it  caused any problems.

As an example, Take one of my minor modifications I make to source
files: if a c++/c file doesn't have a newline before the EOF, I add one.
The only reason I have to do this is because the Visual Studio editor
doesn't think that these are required.  Working in a primarily Microsoft
Shop, getting all our developers to use a proper editor to fix this
before adding files is really not possible.  Before adding my
automation, I was constantly cleaning up other peoples code when I got
warnings/errors on certain unix compilers which are merely ANSI
compliant.

There are possible problems with what I'm doing:

It is possible that a change could be made and committed that resulted
in a NOP revision added to CVS.  I could check for this and abort the
commit from my script, but haven't found the need.  In practice, this
hasn't come up, and if it does, the negatives aren't too strong - slight
waste of space in the repository and some unnecessary compilation on the
clients side, perhaps.

If keyword expansion is not on, the client won't get the modifications
made on the server side.  Couple with our policy of using
keyword-containing headers in all our source files, this doesn't happen
much.  The only time it happens is when someone adds a file to the
repository without the header.  My automation inserts the header for
him.  This might result in the client being out of sync (not a problem,
it's just comments), and even possibly a conflict if the out-of-sync
client then tries to add his header.

I could probably alleviate this problem somewhat by only doing the
processing if keyword expansion is done (another easy thing to add to my
script), but it's never really come up.  This is just conjecture.
Furthemore, for all the rather minor changes I'm making, the out of sync
problem, event if it did occur, doesn't change the functionality of the
code in any way.

If these possible conflicts I've never seen were to occur, the nature of
the changes I'm making is such that resolving them would be trivially
easy.

I wouldn't recommend anyone do this type of code changing lightly. If
you do want to do it, take the time to do it right.  My processing is
hightly configurable.  You can turn it off or modify what actions are
taking for directories , entire treees, or files that match a pattern.
Clients can do this configuratio by checking in small config files in
the appropriate place in the tree.  If any change is made to a file on
the way to bing committed, the original is archived.  In all cases, the
client is notified of all changes done, and where the backup file can be
retreived, if it's needed.  It's never been needed.


Scott

-- 
Sometimes the best medicine is to stop taking something.

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

Re: cvs commitinfo - remote access issues - enforced code beautification

[Thomas S. Urban]

On Wed, Mar 20, 2002 at 16:37:44 -0500, Greg A. Woods sent 1.4K bytes:
<...>
> The source code control tool is not the place to do the beautification.
> 
> You might want to validate the code and reject a commit if it does not
> meet your coding standards, but you should not (and indeed with CVS, can
> not really) try to modify the file being committed in any way.

What do you mean by "can not really"?  I do some modification of
committed files with a script called from commitinfo.  I don't do
anything too severe - clean up trailing white space, add headers in some
instances, make sure files created by broken editors have a new line
before EOF, and one or two other small things.  I guess that qualifies
as mild beautification?  Anyway, I haven't noticed any problems with
this approach in the 6 months or so I've had it turned on.  Any problems
I should be looking for?

<...>

Scott

-- 
Arrakis teaches the attitude of the knife - chopping off what's
incomplete and saying: "Now it's complete because it's ended here."
-- Muad'dib, "Dune"

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

Re: cvs commitinfo - remote access issues - enforced code beautification

[Thomas S. Urban]

On Wed, Mar 20, 2002 at 12:18:26 -0800, Austin Lauree sent 6.4K bytes:
> I am trying to administer our cvs repository to ensure that all java
> code commited runs through a 'beautification' process.
> 
> I setup a test system where CVSROOT/commitinfo contains:
> ALL /scm/cvsscripts/commitscript
> 

> 
> If your CVSROOT is a remote dir, using rsh/ssh/pserver access methods,
> the commitscript runs on the cvs server (the repository host) against
> temporary files that it copies from your working directory.  It does
> NOT reflect the changes made to these temporary files in the client's
> working files, but it does update the client's CVS/Entries file to
> reflect that the commit has been accepted into the repository.  So you
> end up with the 'beautified' code in the repository, cvs thinking you
> have this updated code in your working area when you don't, and a big
> bloody mess, no?

Yeah, I've seem this with my commitinfo scripts.  I think if you ensure
that the files you are working in have CVS/RCS keywords in them (and
keyword expansion is not turned off for those files), the remote client
will get an updated version after the commit. Add a comment header to
all your files with $Id$ or similar in it.  Have your developers use
templates for code that have the keywords in them.



HTH
Scott

-- 
It's reassuring to know that if you behave strangely enough, society will
take full responsibility for you.

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

Re: File sharing

[Thomas S. Urban]

On Wed, Mar 13, 2002 at 13:01:09 -0700, Ben Baker sent 3.0K bytes:
> We're in the process of converting from another source control system
> to CVS and one of the things our previous system did that CVS does not
> is file sharing.  I was just curious if anyone has a solution to this.
> I've thought of a couple of things, but don't want to do too much
> investigation if it's something that definitely won't work.  The ideas
> I had were:
> 
> 1.  Develop a system of watches on certain files so that whenever a
> change is comitted it is automatically comitted to the other shared
> locations.

#1 is going to lead to many problems, for example, what happens when the
two locations are changed independently?

> 2.  Use symbolic links on our CVS server (a UNIX box)

I think that there are also problems with symbolic links in the
repository.

You forgot 3: Don't do repository sharing.

We imported tons of shared stuff from a Source Safe repository to CVS.
The way we handled shares was to eliminate them.  This involved some
factoring of code, creating of libraries, some creative definitions of
cvs modules (sort of sharing on the client side), and in general
improving how our development process worked.  In most cases, sharing in
VSS wasn't done for really good reason.  Improvements to our build
system eliminated 95% of the need for shares.

If you really need sharing in the repository, CVS might not be the
answer.  There was a thread on this list in the not too distant past
that dealt with symbolic links in the repository.  You might search for
it to get more info on that idea.  I haven't seen anyone discuss
building an automated merging system on top of the CVS back end,
probably because it's a pretty bad idea. ;)

HTH
Scott

-- 
You have many friends and very few living enemies.

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

Re: OT: C++, yuck!

[Thomas S. Urban]

On Wed, Feb 27, 2002 at 13:55:35 -0600, Mark A. Flacy sent 0.8K bytes:
> >>>>> "Thomas" == Thomas S Urban <[EMAIL PROTECTED]> writes:
> Thomas> 
> Thomas> On Wed, Feb 27, 2002 at 12:59:48 -0500, Greg A. Woods sent 2.8K bytes:
> >> "dynamic binding" isn't a feature you could ever possibly decide on
> >> needing up front for any kind of project you'd ever even get close to
> >> justifying C for!  Get real!
> Thomas> 
> Thomas> You're wrong. Read what I wrote again.  Projects I am working on satisfy
> Thomas> the description I gave.  Then again, I'm not real, but I'm working on
> Thomas> it.
> 
> In this case, he's correct.  After all, if you need dynamic binding, then
> you can't use C and therefore can't justify using it for said project.  :-)

He's only possible correct in the context left after my original words
are removed.  This is what I wrote:


> > > That is silly.  What if you could justify C, except you need
> > > dynamic binding too? Then could you justify C++?  What about you
> > > need all the features of C, with generic programming as well?
> > > Then is C++ back in


Emphasis on the word *except*.  Is your parser broken, or is my mastery
of the english langauge failing me?


-- 
Breadth-first search is the bulldozer of science.
-- Randy Goebel

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

Re: OT: C++, yuck!

[Thomas S. Urban]

On Wed, Feb 27, 2002 at 12:59:48 -0500, Greg A. Woods sent 2.8K bytes:
> [ On Wednesday, February 27, 2002 at 01:19:22 (-0800), Thomas S. Urban wrote: ]

> 
> I don't really have time to get into a detailed discussion, and
> certainly not in this forum!  ;-)

You don't really have time to get into it - that's funny.

> I recommend you read the published articles, papers, and such that
> describe problems with C++ -- for the most part they've only confirmed
> what I knew intuitively from studying the language directly.
> 
> Alan Kay's comment about OO vs. C++ sums it all up rather nicely though.

I've read quite a bit about C++, problems, design, use, etc.  I'll
gladly read more papers and analysis on the subject (ref or URL?).  Cute
one liner quotes don't really qualify in my book.


> > There are a couple features, like operator overloading, that
> > I think would have been better left out of the langauge, but even those
> > can be fine if used with restraint.
> 
> You see that's a very perfect example of a fundamental flaw with the
> very idea of a language like C++ (or Java or C# or any other attempt to
> describe a half-baked Modula-style language as "object oriented").
> Operator overloading should not be an issue -- it must be a very natural
> and inherent part of any OO language.  Look at the very invention of the
> concept in Smalltalk to see why.

There are many things you can do in C that are a bad idea.  The same
applies to other langauges I'm familiar with. You can effectively use
C++ without operator overloading except in the case when you want to do
generic programming with classes that behave similarly to native types.
Sometimes this is appropriate, sometimes not.

> > In short, C++ is a good langauge if your developers know how to use it,
> 
> Mabye -- but y'all would be much more productive and useful to society
> if you'd try to forget C++ and everything you know about it (right after
> you've re-written all your code in some more cost effective language, of
> course!).

Pttfth.  Maybe you'd be more useful to society if you'd stop trying to
brow-beat the people on the CVS list into your stubborn view of the
world?

> > > If you can't justify using C for a project (on language merits alone)
> > > then C++ is right out of the running from the get go!
> > 
> > That is silly.  What if you could justify C, except you need dynamic
> > binding too? Then could you justify C++?  What about you need all the
> > features of C, with generic programming as well?  Then is C++ back in
> > the running?
> 
> "dynamic binding" isn't a feature you could ever possibly decide on
> needing up front for any kind of project you'd ever even get close to
> justifying C for!  Get real!

You're wrong. Read what I wrote again.  Projects I am working on satisfy
the description I gave.  Then again, I'm not real, but I'm working on
it.




-- 
What's done to children, they will do to society.

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

Re: OT: C++, yuck!

[Thomas S. Urban]

On Wed, Feb 27, 2002 at 02:39:42 -0500, Greg A. Woods sent 3.1K bytes:
> [ On Tuesday, February 26, 2002 at 21:00:34 (-0800), Gianni Mariani wrote: ]
> > Subject: Re: OT:  C++, yuck!
> > 
> > You can't be serious !
> 
> Well yes I am _VERY_ serious about how bad C++ is in general.

Ok, this is way off topic, but I'm curious what you think the bad
features of C++ are?  I keep reading how bad you think it is, but not
really why?  And I mean the langauge, not portability - I talk about
that a bit later.

> > *Every* language has problems.  There is no panacea.
> 
> I couldn't agree more!  C++ just has more than its fair share of
> problems.  ;-)

How do you figure?  C has 6 problems and C++ has 6 + 4, therefore it has
more?

I do a third or more of my professional work in C++, and I generally
like the langauge: it is very appropriate is some circumstances, less so
in others. But I am also of the opinion that it is easy to misuse the
langauge.  There are a couple features, like operator overloading, that
I think would have been better left out of the langauge, but even those
can be fine if used with restraint.

There are some portability problems, but if you're careful, you can
avoid them rather easily - in practice, this typically means avoiding
templates unless you're sure they're supported by all the compilers you
use. For many people, they only have to support up-to-date compilers.
For some older compilers, you might need to avoid namespaces as well.
Supporting really old C++ compilers shouldn't be required of most
development shops, I would hope. Etc.  Really, in my experience, it's
not all that bad.

Their are certain problems that are more easily solved with the features
of C++ than C.  True, they can also be solved by other OO languages, but
C++ is better over those alternatives in many circumstances for other
reasons (availability, libraries, C linking issues, availablity of
tools, and even just the somewhat arbitrary fact that it might be easier
to find developers who know C++ compared to smalltalk, for example.)

In short, C++ is a good langauge if your developers know how to use it,
and it has the features you need, and is apprpriate for your domain
(most of them), and you know you won't have to use some broken compiler
that doesn't support some feature you need.  The same can be said about
most any language I think.

I should be ignoring you rather than feeding the flames of this never
ending thread, but what the hell, it's late and I can't sleep.

My reply above this line is a serious enquiry.  Below this line, I'm
going for insults and laughs only.

HAND/N
Scott

> > I happen to think that C++ has a large number of positive things going 
> > for it
> 
> I think if you could find someone to do a careful and impartial academic
> study of C++ you would find that it has many more negative aspects it
> than it has positive aspects.

I think you're wrong.  No, let me make my completely unsupported opinion
sound more valid.  I think if you do a careful impartial academic
analysis of C++ you'll find that the negative aspects don't outweigh the
positive aspects.  Whatever that means.

> > and it's much further along the track of stabilization than any 
> > other language with it's capabilities.
> 
> What, exactly, can that possibly mean?  If you mean "standardization",
> then you're wrong.

Asserted.  Still waiting 

> Yes I wish ANSI et al would quit messing with C and inventing new
> features and mis-features, but in reality there are more than enough
> good compilers that all implement the same C language that you really
> can't call it unstable in any way.  Common C++ compilers have much more
> variation than C compilers and it is widely known and accepted that C++
> code is inevitably far less portable than C code unless you stick to one
> multi-platform compiler.

Is this in regards to the C98 (or is it C99) specification?  How
portable are those features right now ;)  I think your "far-less
portable" might be a little exagerated. No, make that exagerated from
here to the moon and back.  It all depends on your domain (archs,
compilers, features).  Damn it, I'm getting to serious again.

> > So, even though C++ has "niggling yucky details" it is the Right(tm) 
> > choice for many applications; and for a large subset, the only suitable 
> > language.
> 
> Oh, P'llze!  You've got to be kidding.  Either that or you've been
> poorly brainwashed, or have gone insane, or something.

Either you like to have sex with goats or you're are wrong.  Please pick
one.

> I've read articles and papers that just barely manage to justify the
> choice of C++ for some projects, but they only succeed at this
> justification by hiding all but a tiny set of token problems under their
> not so perfect carpets.

Greg read articles.

> I've read multiple rebutals to those articles and papers which give more
> than equal justification for choosing alternate languages.

Then he read some rebuttals.

He agreed with the

Re: refactoring when using CVS

[Thomas S. Urban]

On Fri, Feb 22, 2002 at 17:01:44 -0500, Greg A. Woods sent 1.8K bytes:
> Yeah, and you 'Mericans might pressure us into something like that too.
> Hevean help us if the bloody Canadian Alliance party gets power in this


This has nothing to do with CVS nor with the subject "refactoring when
using CVS".  Change the subject, added "OT", or better, take this
conversation elsewhere.

Thanks
Scott


-- 
Never offend people with style when you can offend them with substance.
-- Sam Brown, "The Washington Post", January 26, 1977

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

Re: CVS Update Behaviour

[Thomas S. Urban]

On Thu, Feb 21, 2002 at 20:00:23 -0500, David Fuller sent 1.5K bytes:
> Colm Murphy wrote:

> >directory. This is setup by defining a module to contain only certain 
> >files.
> >
> >All is fine until the developer does an cvs update.
> >The current behaviour is that all existing files are updated (which is 
> >fine) but all other files in the directory are checked out.

> This is a flaw in CVS that tracks back to the modules file.  While you 
> can set up modules like the one you are talking about, CVS only looks at 
> the modules file when you check out a module.  Update, etc, don't check 
> against the modules file after that.  This is why you are seeing this 
> behavior.

Also note that you can re-checkout the same module, which acts like
update in the sense you want it to - it will update only those files
that are part of the module.  This is also good if you add files/dirs
to the module - it's doesn't prune files and dirs if you remove them
from the module definition, however.  A bit of a work around, but maybe
it will help you.

Scott


-- 
no name, no slogan

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

Re: VSS to CVS

[Thomas S. Urban]

On Mon, Feb 18, 2002 at 03:14:30PM +, Nick A Edwards wrote:
> I am looking for a utility which will allow me to converts a Microsoft
> Visual Source Safe (6.0) to CVS (currently 1.0.6). I need to make sure
> that historic versions are also taken.

I went through this exercise earlier this year.  I used the vss2cvs
perl scripts others have replied with:

http://www.laine.org:8080/cvs/vss2cvs/

The biggest problems I had were:
1 vss2cvs imports everything - I wanted to ignore certain binary files
  and have more control over the import (control recursion, etc.)
2 shared files in VSS got imported into CVS multiple times - indeed,
  you'll probably find that dealing with shares (and broken shares) in
  VSS is the hardest part of the process - I dealt with most of this by
  either restructuring / refactoring code into libraries and the use of
  CVS modules after the import was completed
3 the import can take a long time, mostly because of the above two
  problems

To deal with these problems, I added some features to vss2cvs.pl to deal
with 1 & 2, and wrote some other scripts to deal with the files after
import.  3 is alleviated somewhat by these changes, but it still took a
while for the 11000 files, 38000 revisions I imported.

I sent the changes I made to Laine, but never received any reply nor saw
that he incorporated any changes in his download site.  If you're
interested in them, let me know and I'll send them to you.

Just a warning, depending on how your VSS repository is set up, this
process can be a bit of a PITA.

Scott

-- 
The wages of sin are high but you get your money's worth.

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

Re: Get list of modified files?

[Thomas S. Urban]

On Fri, Jan 11, 2002 at 05:39:44PM -0500, Peter Davis wrote:
> Forgive me if this is a frequently asked question (*I've certainly wondered
> often enough*), but is there a way to get a list of modified files?  I've
> tried "cvs -n commit", which seems like it should work, but it doesn't list
> the modified files.

cvs -n update

(see cvs --help-options)

Look for lines that begin with M (modified) or C (conflicted)

Useful aliases (csh syntax):

alias cvsquery 'cvs -n update \!* |& grep "^[MCUP?] "'
alias cvsmodified 'cvs -n update \!* |& grep "^[MC] "'

then

cvsquery
cvsquery [-l] [files or dirs]
cvsmodified
cvsmodified [-l] [files or dirs]
etc

Scott

-- 
Lockwood's Long Shot:
The chances of getting eaten up by a lion on Main Street
aren't one in a million, but once would be enough.

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

Re: modifying vss2cvs.pl to ignore certain files

[Thomas S. Urban]

On Thu, Jan 10, 2002 at 12:28:48PM +0100, Kim Bækgaard wrote:
> "Thomas S. Urban" <[EMAIL PROTECTED]> wrote in message
> > I'm using the 'vss2cvs.pl' to move all VSS projects to CVS at our
> > company.
> 
> This looks like exactly what I need - where can I find vss2cvs?


You can find the original script at:

http://www.laine.org:8080/cvs/vss2cvs

I sent the maintainer a version that adds additional options
- turn sub-directory recursion off
- not import files with specified extensions (e.g. .lib, .exe)
- ignore all binary files for import

I have another change that only imports shared files from vss into cvs
once - the next time it encounters a shared file previously imported, it
checks a simple file into the appropriate cvs repository telling where
the file exists in cvs and lists all the shares.   I'm still working on
it, so haven't sent it to the maintainer yet.


Scott


-- 
The surest sign that a man is in love is when he divorces his wife.

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

modifying vss2cvs.pl to ignore certain files

[Thomas S. Urban]

Hi

I'm using the 'vss2cvs.pl' to move all VSS projects to CVS at our
company.  It seems to be working well, but it is taking a very long
time.  I did a trial import of just one small part of our VSS
repository, and because of sharing with other projects in VSS, it took
serveral hours and put 35MB of files in the CVS repository.

I an wondering if I can prevent the script from processing binary files
(.doc, .lib, .exe) files in CVS, of which there are many, if it might
save time and disk space.  These files ultimately won't be stored in CVS
anyway.

So after a quick look through vss2cvs.pl, it looks like I have several
places where I could do a regex on file extension, but not knowing a
great deal about how the script works, I thought I'd check to see if
anyone has tips/advice.  Here are the possibilities I see:

 - in the loop that processes 'dirlist' and writes to 'ssfiledump'

 - in the loop that reads 'ssfiledump' before calling 'resync_file()'

 - in resync_file()

I'd also like to add an option (or env var as other options are
processed) to specify lists of file extension to ignore.



TIA
Scott

-- 
Some men are discovered; others are found out.

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

Re: difficult modules setup question

['Thomas S. Urban']

That seems to work.  Excluding directories is a better solution
than list files since direcotires seem to change less frequently that
files.

Thanks,
Scott.

On Fri, Dec 21, 2001 at 11:08:02AM -0800, Jerry Nairn wrote:
> The modules documentation is hard to follow, I suspect because these
> features were not carefully planned. Here's a method you don't seem to have
> tried.

> ##
> _topfiles -a !top/libraries !top/apps top 
> ##


-- 
Love may laugh at locksmiths, but he has a profound respect for money bags.
-- Sidney Paternoster, "The Folly of the Wise"

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

difficult modules setup question

[Thomas S. Urban]

My organization has been using CVS for a while, and our usual practice
of having everyone checkout the entire tree is becomming cumbersome.
Beyond the steady growth of the CVS repository, we are about to move the
rest of the company from Source Safe to CVS.  I am trying to set up the
module such that developers can easily check out only those pieces they
need.  Ideally, overlap between modules should result in only a single
checkout in the sand box.  This  is a greatly simplified view of what
our repository looks like.  The build files under top are required by
all projects, but everything else depends on the module.


Repository:
top/
build.file.1
build.file.2
build.file.3
libraries/
lib1/
lib2/
lib3/
lib4/

apps/
app1/
app2/
app3/


Modules 1 is 'app1', requires lib1, lib2, build files, this is what the
sandbox should look like after 'cvs co app1':

top/
build.file.1
build.file.2
build.file.3
libraries/
lib1/
lib2/
apps/
app1/

Module 2 is 'app2', requires lib2, lib3, build files, this is what the
sandbox should look like after 'cvs co app2':

top/
build.file.1
build.file.2
build.file.3
libraries/
lib2/
lib3/
apps/
app2

A developer working on module 1 and module 2 should get a sandbox that
looks like this after 'cvs co app1 ; cvs co app2':

top/
build.file.1
build.file.2
build.file.3
libraries/
lib1/
lib2/
lib3/
apps/
app1
app2

I am having a great deal of difficulty setting up the modules to acheive
this result.  If I define these modules:

_libraries_lib1 -a  libraries/lib1
_libraries_lib2 -a  libraries/lib2
_libraries_lib3 -a  libraries/lib3
_apps_app1  -a  apps/app1
_apps_app2  -a  apps/app2
_apps_app3  -a  apps/app3

app1-d top  &_libraries_lib1 &libraries_lib2 \
&_apps_app1
app2-d top  &_libraries_lib2 &libraries_lib3 \
&_apps_app2

This gets everything but the build files under 'top/' (which there are
many of, and I'd prefer not to list them separately).  (off-topic, but
the rhs of the aliases in these commands are *not* complete relateive
path names from CVSROOT (don't include 'top/'), but cvs seems to check
them out ok anyway ??).

I can't figure out how to get the build files where I need them.  I've
tried:

_build_files-a  -l top

but cvs complains about using '-a' with other options. If I do:

_build_files-l top

and then add it to the real modules, eg:
app2-d top  &_libraries_lib2 &libraries_lib3 \
&_apps_app2 &_build_files

I end up with the build files in top/_build_files/ Not what I want.

If I modify _build_files above to:

_build_files-d top -l top

the build files end up in top/top/, again, not what I want.  Changing it
to

_build_files-d . -l top

results in cvs errors.  Is there anyway to do what I want with the
current module system short of listing each file I want under 'top/'
individually for the module?

If I can't find a solution with the modules, I know I can move all the
build files to a separate subdirectory, but I'd rather not do this
because it would require modification of build files throughout our tree
and in several branches.


TIA
Scott


P.S.  I'm using _ prefixes to denote modules that are internal, and not
meant to be checked out directly.  Any interst in a patch to cvs to get
'cvs co -c' to not output these (or better, some user definable
'internal' pattern for modules)?




-- 
Many a man has fallen in love with a girl in a light so dim he would
not have chosen a suit by it.
-- Maurice Chevalier

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

Re: Getting log messages via email

[Thomas S. Urban]

On Tue, Dec 18, 2001 at 05:08:53PM +0100, Joern Kersten wrote:
> Hi!
> 
> I'd like to get an email notification *including the log message* when
> somebody is committing changes to certain files. Currently, I'm using
> cvs watch and the standard command in CVSROOT/notify,
> 
> ALL mail %s -s "CVS notification"

This might be overkill for what you want, but I use a perl script to
assemble and format the mail message and also link to your cvsweb
interface for viewing the differences.

This is what I have in CVSROOT/notify:
ALL /usr/local/cvs/bin/cvsnotify.pl %s

And this is the perl in /usr/local/cvs/bin/cvsnotify.pl (change cvsroot
and the CVS web url and whatever else to make it work for you):

--- begin cvsnotify.pl ---
#!/usr/bin/perl
# notes:
#
# this script is run by CVS to notify users of changes
# a copy or link of this should be placed in /usr/local/cvs/bin,
# or the location/name should be changed in the 'notify' support
# file (check out in CVSROOT)
#
#- TODO: doesn't tell what happened (add,change,remove)
#- TODO: doesn't work right for removed files (URL, log)
#- TODO: doesn't work right for added files (URL, log)
#- TODO: use env $CVSROOT for $cvsroot
#

# config vars
$cvsroot = '/YOUR/CVSROOT';
$cvsweb_base = "http://YOUR.CVSWEB.MACHINE/cgi-bin/cvsweb.cgi";;

# user's email address, aliases from 'users' file in CVSROOT
$useraddr = shift @ARGV;

# notify info is passed in on 
@lines = <>;

$line = shift @lines;

# remove trailing newline
chop $line;

# module and file
($module,$file) = split (' ',$line);

# ignore lines
shift @lines;
shift @lines;

# changed
$line = shift @lines;
($nop, $changer) = split (' ',$line);

# use rlog to get 'rcs' info
$rlog_file = $cvsroot . $module . "/" . $file . ",v";
$rlog_cmd = "rlog -zLT -r " . $rlog_file;

open (RLOGOUTPUT, "$rlog_cmd |") or die "can't run rlog";

while ()
{
if (/^head: (.*)$/) { $head = $1; }
if (/^branch: (.*)$/) { $branch = $1; }
if (/^date: /) { last ; }
}

# assemble log message
while ()
{
if (/^=/) { last; }
push @log_msg, $_;
}

close (RLOGOUTPUT);

# assemble mail message
open (MAILINP, "| mail -s '[CVS notify] $module changed' $useraddr");

print MAILINP "This is an automated message generated by CVS.\n";
print MAILINP "If you do not wish to receive these messages, use\n";
print MAILINP "'cvs watch' to modify your watches.\n\n";
print MAILINP "module: $module\n";
print MAILINP "file: $file\n";
print MAILINP "head: $head\n";
print MAILINP "date: $dat\n";
print MAILINP "log message:\n", join ('', @log_msg), "\n\n";

$head =~ m/^([^.]*)\.(.*)$/;
$whole = $1;
$part = $2 - 1;
$lhead = $whole . "." .  $part;

print MAILINP "see changes at: 
$cvsweb_base/$module/$file.diff?r1=text&tr1=$lhead&r2=text&tr2=$head&f=h";

close MAILINP;

--- end cvsnotify.pl ---


HTH
Scott

-- 
If you can't be good, be careful.  If you can't be careful, give me a call.

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

Re: Keeping different platforms in sync?

[Thomas S. Urban]

Have you looked at 'rsync'?  I don't know if handles the text file
conversions offhand, but I know it runs on both windows and unix
platforms and is pretty powerful otherwise.

On Tue, Sep 18, 2001 at 03:58:38PM +0100, Stephen Jowitt wrote:
> Hi,
> 
> We're currently using cvs and I have to investigate how we can
> best keep our source code in sync on both the platforms used by the
> developers.
> 
> We develop for Windows and Linux and both systems share source code from
> 
> the same repository. Our developers would like to be able to do the
> following:
> 
>   1) Write code on windows machine. Compile and test.
>   2) Compile and test the same code on a linux box
>   3) Commit changes to cvs
> 


-- 
You have taken yourself too seriously.

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