Re: 'checkoutinfo' trigger?

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jim.Hyslop <address@hidden> writes:

> Mark D. Baushke wrote:
> [snip use-case]
> > This differers from your case where only a
> > portion of the repository is restricted.
>
> Interesting. Same idea, different subsections
> (as you say, an inverse of our requirements).
> 
> > I would think that the solution to your problem
> > would be that the commit triggers for your new
> > co-op code would open the umask for newly added
> > directories and files to be 000 to allow anyone
> > access to those files.
>
> Hmmm... this might work. This would require
> whoever adds a directory to also immediately
> check in a file, because commitinfo will run
> only when files are checked in. Before
> permissions are adjusted, if anyone in the other
> group tries a 'cvs update -d', or anything else
> that tries to recurse into the new directory,
> cvs will abort because it can't lock the
> directory.

You could also run it from loginfo. loginfo is run
for a newly added directory.

> > If you do feel some kind of trigger on checkout
> > is needed, you will need to consider:
> [lots of stuff]
>
> Thanks for those points to ponder. Of the 8
> add-ons you mentioned, I'm only familiar with
> two (CVSweb and ViewCVS) - I'll have to
> familiarize myself with the others (if for no
> other reason to see if they would be useful for
> us :-)

Heh. Yeah, there are lots of things that have been
written by folks over the years to help maintain
or collect the metadata of CVS out-of-band.

> I'll think on this some more, and if I come up
> with a more complete proposal I'll post it here
> for further discussion.

Sure.

        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFCHMk23x41pRYZE/gRAuKpAJ9z3bjk9fK7mOQ319wlPE5CYh4GbACgzN1g
G7/BdhIzdk172wqlqj5ALgI=
=npdQ
-----END PGP SIGNATURE-----