Re: (no subject)

[Mark D. Baushke]

> From: Baris Sahin <address@hidden>
> Subject: Re: (no subject)
> To: address@hidden
> Cc: address@hidden
> Sender: address@hidden
> Date: Tue, 3 Sep 2002 04:05:26 -0700 (PDT)
> 
> hi,cvs doesnt pass branch information to commitinfo file,so you cant
> use commitinfo for that.I had the same problem, and then solved with
> writing a patch for access control. Available at
> http://www.geocities.com/barissahin/

While it is true that the commitinfo script is not given any explicit
arguments about the branch, this does not mean that you can not find out
this information.

The commitinfo script is running in a directory where the files given on
the command line reside as local files. There is also a copy of the CVS
directory present and the CVS/Entries file contains the branch information
if you want to parse it. There are two ways you could get that information.

You may either write a script to 'manually' parse the CVS/Entries file
something like the following perl script fragment:

  open(ENTRIES, $ENTRIES) || die("Cannot open $ENTRIES.\n");
  while (<ENTRIES>) {
    chomp;
    # /file/ver/timestamp/options/tag_or_date
    my($filename, $version,$ts,$opt,$tag) = split('/', substr($_, 1));
    $cvsversion{$filename} = $version;
    # the /^D/ date specification for a tag should not be possible in a commit
    # so ignore it
    if ($tag eq '' || $tag =~ /^T/) {
        $cvsbranch{$filename} = $tag;
    }
    $cvsoption{$filename} = $opt;
  }
  close(ENTRIES);

It should also be possible to do something like:

  cvs -Qn status filename

and parse the 'Sticky Tag:' line in your script.

This does not require any patches to cvs at all.

        -- Mark

> baris
> 
> --- address@hidden wrote:
> ---------------------------------
>  A simple question. Can I discover on which branch a file is being
>committed from withina script run from the commitinfo file? Basically,
>I know how to apply per user/module access controls, but I would like
>to extend this to include branch information so that certain teams are
>confinedto branches. We have in the past experienced code fixes being
>applied to thewrong branch and it would be preferable for the
>technology to help people avoidthat mistake in the future.