Re: [Gnu-arch-users] Re: multiple committers, again

[Robert Anderson]

--- Original Message ---
From: Stefan Monnier <address@hidden>
To: address@hidden
Subject: [Gnu-arch-users] Re: multiple committers, again

>>> If there was some kind of context that was detectable in a
>>> startup file that said "this is a tla ssh session" then I could
>>> set umask accordingly and that would work fine, and it wouldn't
>>> compromise every other use of that startup file.
>
>> I can think of half a dozen different ways to do it just
offhand. You
>> aren't even trying.

>Hopefully it should be possible to set things up without having
to think too
>hard first.  E.g. by following some instructions.
>
>I for one have no idea how to change the umask used when I access my
>archive via sftp.

That makes two of us that aren't even trying, I guess.

>  Googling indicates this was discussed here with
>suggestions like sftp%umask=XXX:/foo/bar/baz (which I must say
doesn't
>sound right: the umask setting should be in the archive itself,
so as to
>make sure noone creates stuff with the wrong umask by mistake).
>
>But is it necessary to change one's umask just to commit?

If you want people other than you to commit after you do, and
your umask otherwise strips g+w, the answer is yes, you do.

>After all, committing should only need to create an immutable
changeset
>and add it to a preexisting directory, so nothing it creates
needs to be
>writable, right?  Or is it due to locking?

The error message you get is something about locking.  But I
think it is more than that - I think the new patch directory is
created in the archive in a directory owned by the last person to
commit, before being moved into its new location alongside the
rest of the patches.

This also makes for some pretty confusing/counterintuitive dir
ownership in the resulting patch directories.  It seems like the
owner of the patch-N directory is determined by who committed
patch-(N-1). 

>I think the page
http://wiki.gnuarch.org/moin.cgi/Centralized_20Development
>is pretty confusing in that it lists several options without
making it quite
>clear why there needs to be several options.  E.g. who'd bother
patching
>ssh when you can do without it?

Well there are various constraints on people's work environments
that might make various options more palatable over others.

But in my case, which I don't think is too unusual, none of the
options listed are workable.

Maybe Andrew could list a mere 3 or 4 of his ideas for how to do
this.  If it's not obvious to Stefan then I have even less shame
admitting that I haven't a clue how to do it, either.

Thanks,
Bob