Re: [Savannah-hackers-public] Re: savannah shell access?

[Bob Proulx]

Jim Meyering wrote:
> I'll be happy to move things to
>   /var/lib/git/git-to-cvs
> once things are settled -- or wherever else seems appropriate.

I am thinking about the problem now and trying to decide whether
/var/cache/git-to-cvs is more appropirate than /var/lib/git-to-cvs.
Using /var/cache just "feels" like the better location to me.

  http://www.pathname.com/fhs/pub/fhs-2.3.html#VARCACHEAPPLICATIONCACHEDATA
  http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION

I would be cautious about using small, short, generic names like "git"
because of possible name collisions as the name here in case the git
project itself eventually starts to use a /var/ location and creates a
collision.  A top level project name unique to this task should
probably be used instead.

And what if this were expanded to be offerred to other version control
systems (without starting discussion -- such as 'arch' or something)
then would this cache be useful there too?  In which case I am
thinking that perhaps /var/cache/git-srv or something slightly longer
and more reliably avoiding name collisions might be good.

But since things can be modified in the event of actual found problems
I don't feel strongly about this.

> One small measure that may help avoid casual or inadvertent
> interference: leave each working directory "chmod 0", and have
> the git update hook do "chmod 755 ...", do its job, then "chmod 0"
> to re-protect it.

I think this is not so good.  I understand how it would make it more
difficult to have accidental crosstalk between projects happen by
making the windows of vulnerability smaller, like a time-lock safe.
But I think that if there is a concern about interference that the
process either should stand on its own or not.  Withing being able to
completely verbalize why, I think that doing this type of door opening
and closing just "feels" like less than a good thing to do.

Bob