Обсуждение: Protections problem on CVS tree

Hi. I had ftp'd in all the files for the new ODBC code in the main
Postgres tree. I forgot to change the protection on the derived
odbc/configure file, so it is checked in without execute permission.

Do you have any experience fixing this kind of problem? Simply checking
in a new version with the right permissions doesn't seem to fix it. The
two alternatives I'm considering are:- "cvs delete" then "cvs add" the file with the right permissions- going into the
cvstree itself and brute-force change it
 

Suggestions? If you know what to do, and want to do it, feel free to fix
it. I'm inclined to try the brute-force method, but remote CVSup trees
(like mine) may need the same kludge fixup :O
                  - Tom

> Hi. I had ftp'd in all the files for the new ODBC code in the main
> Postgres tree. I forgot to change the protection on the derived
> odbc/configure file, so it is checked in without execute permission.
> 
> Do you have any experience fixing this kind of problem? Simply checking
> in a new version with the right permissions doesn't seem to fix it. The
> two alternatives I'm considering are:
>  - "cvs delete" then "cvs add" the file with the right permissions
>  - going into the cvs tree itself and brute-force change it
> 
> Suggestions? If you know what to do, and want to do it, feel free to fix
> it. I'm inclined to try the brute-force method, but remote CVSup trees
> (like mine) may need the same kludge fixup :O

Go to $CVSROOT/pgsql, and fiddle wit hthe protections of the base files,
no?


--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

On Wed, 21 Oct 1998, Thomas G. Lockhart wrote:

> Hi. I had ftp'd in all the files for the new ODBC code in the main
> Postgres tree. I forgot to change the protection on the derived
> odbc/configure file, so it is checked in without execute permission.
> 
> Do you have any experience fixing this kind of problem? Simply checking
> in a new version with the right permissions doesn't seem to fix it. The
> two alternatives I'm considering are:
>  - "cvs delete" then "cvs add" the file with the right permissions
>  - going into the cvs tree itself and brute-force change it
> 
> Suggestions? If you know what to do, and want to do it, feel free to fix
> it. I'm inclined to try the brute-force method, but remote CVSup trees
> (like mine) may need the same kludge fixup :O

hub> ls -lt
total 967
-r--r--r--  1 thomas   pgsql   11086 Oct 21 01:39 GNUmakefile.in,v
-r-xr-xr-x  1 thomas   pgsql   65482 Oct 21 01:23 configure,v


permissions appear to be fine in the repository itself...and I just
checked it out:

-rw-r--r--  1 scrappy  wheel   8844 Oct 21 14:46 configure.in
-rwxr-xr-x  1 scrappy  wheel  60983 Oct 21 14:46 configure

Marc G. Fournier                               scrappy@hub.org
Systems Administrator @ hub.org                    
scrappy@{postgresql|isc}.org                       ICQ#7615664

> permissions appear to be fine in the repository itself...and I just
> checked it out:

Yeah, I went ahead and tried the brute-force fix (at Bruce's suggestion,
so problems are all his fault :), apparently before you looked at it.
Seems to be behaving fine.
                    - Tom