[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 'checkoutinfo' trigger?

From: Mark D. Baushke
Subject: Re: 'checkoutinfo' trigger?
Date: Wed, 23 Feb 2005 10:19:34 -0800

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.


        -- Mark
Version: GnuPG v1.2.3 (FreeBSD)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]