patchMake git-cvsexportcommit "status" each file in turn

> Hi,
> 
> It turns out CVS doesn't always give the status output in the order
> requested. According to my local CVS gurus this is a known CVS issue.
> 
> The attached patch just makes the script check each file in turn. It's
> slower but correct.
> 
> I also slightly formatted the warn output when it detects problems as
> multiple line wraps with long file paths where making my eyes bleed :-)
> 

> ---
>  git-cvsexportcommit.perl |   30 ++++++++++++++++++++----------
>  1 files changed, 20 insertions(+), 10 deletions(-)
> 
> diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
> index e9832d2..ee02c56 100755
> --- a/git-cvsexportcommit.perl
> +++ b/git-cvsexportcommit.perl
> @@ -182,15 +182,21 @@ if (@canstatusfiles) {
>        my @updated = safe_pipe_capture(@cvs, 'update', @canstatusfiles);
>        print @updated;
>      }
> -    my @cvsoutput;
> -    @cvsoutput= safe_pipe_capture(@cvs, 'status', @canstatusfiles);
> -    my $matchcount = 0;
> -    foreach my $l (@cvsoutput) {
> -        chomp $l;
> -        if ( $l =~ /^File:/ and  $l =~ /Status: (.*)$/ ) {
> -            $cvsstat{$canstatusfiles[$matchcount]} = $1;
> -            $matchcount++;
> -        }
> +
> +    # We can't status all the files at once as CVS doesn't gaurentee
> +    # that it will output the status bits in the order requested.
> +
> +    foreach my $f (@canstatusfiles)
> +    {
> +	my $cvscmd = join(' ', @cvs)." status $f";
> +	my $cvsoutput = `$cvscmd`;
> +
> +	# slurp out the status out of the result
> +	my ($status) = $cvsoutput =~ m/.*Status: (\S*)/;
> +
> +	$opt_v && print "Status of $f is $status\n";
> +
> +	$cvsstat{$f} = $status;
>      }
>  }
> 

> 
>  
> @@ -198,10 +204,14 @@ if (@canstatusfiles) {
>  foreach my $f (@afiles) {
>      if (defined ($cvsstat{$f}) and $cvsstat{$f} ne "Unknown") {
>  	$dirty = 1;
> -	warn "File $f is already known in your CVS checkout -- perhaps it has been added by another user. Or this may indicate that it exists on a different branch. If this is the case, use -f to force the merge.\n";
> +	warn "File $f is already known in your CVS checkout.\n"
> +	warn "  Perhaps it has been added by another user.\n"
> +	warn "  Or this may indicate that it exists on a different branch.\n"
> +	warn "  If this is the case, use -f to force the merge.\n";
>  	warn "Status was: $cvsstat{$f}\n";
>      }
>  }
> +
>  # ... validate known files.
>  foreach my $f (@files) {
>      next if grep { $_ eq $f } @afiles;
> -- 
> 1.5.2.3
> 

> On Wed, Aug 15, 2007 at 02:27:28PM +0100, Alex Bennee wrote:
> > Hi,
> > 
> > It turns out CVS doesn't always give the status output in the order
> > requested. According to my local CVS gurus this is a known CVS issue.
> <snip>
> I inlined the patch for easier commenting. Please inline further
> patches.

> 
> > ---
> >  git-cvsexportcommit.perl |   30 ++++++++++++++++++++----------
> >  1 files changed, 20 insertions(+), 10 deletions(-)
> > 
> > diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
> <snip>
> This is extremly wastefull, because it will spawn a CVS process for each file.
> A better fix would be to parse the filename from the output of
> 'cvs status' and use that as input for $cvsstat.
> 
> (And/or you could use an hash instead of an array for 'cvsoutput', so
> you could double check that you only get the status for those files you
> asked for.)

> On Wed, 2007-08-15 at 16:04 +0200, Peter Baumann wrote:
> > On Wed, Aug 15, 2007 at 02:27:28PM +0100, Alex Bennee wrote:
> > > Hi,
> > > 
> > > It turns out CVS doesn't always give the status output in the order
> > > requested. According to my local CVS gurus this is a known CVS issue.
> > <snip>
> > I inlined the patch for easier commenting. Please inline further
> > patches.
> 
> Will do. I assumed Evolution would do something sensible. My mistake :-(
> 
> > 
> > > ---
> > >  git-cvsexportcommit.perl |   30 ++++++++++++++++++++----------
> > >  1 files changed, 20 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
> > <snip>
> > This is extremly wastefull, because it will spawn a CVS process for each 

> > A better fix would be to parse the filename from the output of
> > 'cvs status' and use that as input for $cvsstat.
> > 
> > (And/or you could use an hash instead of an array for 'cvsoutput', so
> > you could double check that you only get the status for those files you
> > asked for.)
> 
> I agree it's wasteful and could be done better however I'm no perl
> hacker so I just went for something that was correct and worked. 
> 
> The path that is echoed later in the status output is however the CVS
> file path which may not be directly related to the actual path in your
> source tree. For example I have one status reported as:
> 
> $ cvs status src/proj_version
> ===================================================================
> File: proj_version      Status: Up-to-date
> 
>    Working revision:    1.1.380.1
>    Repository revision: 

>    Sticky Tag:          ATAG (branch: 1.1.380)
>    Sticky Date:         (none)
>    Sticky Options:      (none)
> 
> This makes the matching more than a little problematic.

> For my part it's a fire and forget script once I've finished my hacking
> in a git tree so I don't mind it taking some time. I'm not particularly
> minded to dig further in perl to make it faster unless there is a real
> clamour - or perhaps someone with a bigger itch and more perl foo can
> tackle it.