Raymond Hettinger wrote:
> Part of the mechanics also involves getting the users set-up on their
> own machines. For me, it was a complete PITA because of the
> Tortoise/Putty/Pageant/SSH2 dance and then trying to get Python to
> compile with the only compiler I had (MSVC++6). The advantage of a
Tim Peters wrote:
> [Martin v. Löwis]
>> I completely agree. Just make sure you master the mechanics of adding
>> committers.
>
> So there's a practical problem: is that procedure documented
> somewhere?
I once posted the procedure to all current pydotorg project admins.
I hesitate to post the p
[Raymond Hettinger]
> Part of the mechanics also involves getting the users set-up on their
> own machines.
Yes.
> For me, it was a complete PITA because of the
> Tortoise/Putty/Pageant/SSH2 dance and then trying to get Python to
> compile with the only compiler I had (MSVC++6). The advantage of
Tim Peters wrote:
>[Tim Peters, on giving commit privs to a sprinter after
> extracting a signed PSF contributor form]
>
>
>>>The more realistically ;-) I try to picture the suggested
>>>alternatives, the more sensible this one sounds. ...
>>>
>>>
>
>[Martin v. Löwis]
>
>
>>I completely
[Tim Peters, on giving commit privs to a sprinter after
extracting a signed PSF contributor form]
>> The more realistically ;-) I try to picture the suggested
>> alternatives, the more sensible this one sounds. ...
[Martin v. Löwis]
> I completely agree. Just make sure you master the mechanics of
Tim Peters wrote:
> The more realistically ;-) I try to picture the suggested
> alternatives, the more sensible this one sounds. Some people at the
> sprint (like me, wrt the Iceland sprint) could volunteer to be
> responsible for checking checkins for appropriateness, and in any case
> everyone s
[Martin v. Löwis]
> ...
> Or, to put it yet in a different way: whether or not commit privileges
> are restricted, you need to add the sprinters to the committers list
> first, unless you want to allow anonymous commits to these branches.
>
> Just to not be mistaken: it is technically fairly easy t
Greg Ewing wrote:
> Tim Peters wrote:
>> Instead it would make best sense for each
>> sprint project to work in its own branch, something SVN makes very
>> easy, but only for those who _can_ commit.
>
> There's no way of restricting commit privileges to
> a particular branch?
In the current setup
Martin v. Löwis wrote:
> Benji York wrote:
>>Subversion 1.3 added a path-based authorization feature to svnserve.
>
> That's what I mean by "does not work fine": I would need to update
> to subversion 1.3.
I noted that in my original message. I thought you meant that it wasn't
possible at all w
"Martin v. Löwis" wrote:
> Tim Peters wrote:
>> Since I hope we see a lot more of these problems in the future, what
>> can be done to ease the pain? I don't know enough about SVN admin to
>> know what might be realistic. Adding a pile of "temporary
>> committers" comes to mind, but wouldn't re
Tim Peters wrote:
> Instead it would make best sense for each
> sprint project to work in its own branch, something SVN makes very
> easy, but only for those who _can_ commit.
There's no way of restricting commit privileges to
a particular branch?
--
Greg
_
Benji York wrote:
>>> I'm not familiar with the mechanics, recent versions of Subversion
>>> allow per-directory security.
>>
>> It works fine for http(s), but not for svn+ssh.
>
> Versions prior to 1.3 could use Apache's authorization system.
How would that work? Apache is not involved at all.
Martin v. Löwis wrote:
> Benji York wrote:
>
>>I'm not familiar with the mechanics, recent versions of Subversion allow
>>per-directory security.
>
> It works fine for http(s), but not for svn+ssh.
Versions prior to 1.3 could use Apache's authorization system.
Subversion 1.3 added a path-based
Benji York wrote:
> I'm not familiar with the mechanics, recent versions of Subversion allow
> per-directory security. We do this to give some customers read access
> to parts of the repo, and read-write to others. It shouldn't be
> difficult (given a recent enough Subversion) to set up a spri
Paul Moore wrote:
> Is it possible to create a branch in the main Python svn, and grant
> commit privs to that branch only, for sprint participants? I seem to
> recall something like mod_authzsvn being involved, but I don't know
> much more...
We couldn't technically enforce it - but I'm sure spr
Paul Moore wrote:
> Is it possible to create a branch in the main Python svn, and grant
> commit privs to that branch only, for sprint participants?
I'm not familiar with the mechanics, recent versions of Subversion allow
per-directory security. We do this to give some customers read access
to
On 5/5/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> Since I hope we see a lot more of these problems in the future, what
> can be done to ease the pain? I don't know enough about SVN admin to
> know what might be realistic. Adding a pile of "temporary
> committers" comes to mind, but wouldn't rea
Martin v. Löwis wrote:
> I think Fredrik Lundh points to svk at such occasions.
SVK makes it trivial to mirror a remote SVN repository, and make zillions
of local light-weight branches against that repository (e.g.one branch
per bug you're working on); see e.g.
http://gcc.gnu.org/wiki/SvkHel
On Friday 05 May 2006 15:16, Tim Peters wrote:
> While that may be unavoidable for Bug Days, a major difference for
> the sprint is that little of the code is likely _intended_ to end
> up on the trunk at this time.
Given where we are in the 2.5 release cycle, I'd _hope_ that only safe
changes a
Tim Peters wrote:
> Since I hope we see a lot more of these problems in the future, what
> can be done to ease the pain? I don't know enough about SVN admin to
> know what might be realistic. Adding a pile of "temporary
> committers" comes to mind, but wouldn't really work since people will
> wa
On 5/4/06, Tim Peters <[EMAIL PROTECTED]> wrote:
>
> Since I hope we see a lot more of these problems in the future, what
Me too.
> can be done to ease the pain? I don't know enough about SVN admin to
> know what might be realistic. Adding a pile of "temporary
> committers" comes to mind, but
There's going to be a Python sprint in Iceland later this month, and
it raises some management issues we also see on Bug Days, but more so:
a relatively large number of people slinging code without commit
privileges, and a relative handful with commit privileges. The latter
end up spending all th
22 matches
Mail list logo
