[SAC] Subversion is 403 right now

Tyler Mitchell tylermitchell at shaw.ca
Mon Jan 22 11:30:31 EST 2007


Sounds good to me... I know I need to use something that ties all my  
tasks together too.  I'm curious to see how far I could use this for  
tracking my own work.

Tyler

On 22-Jan-07, at 8:21 AM, Jason Birch wrote:

> I'd prefer to see a single OSGeo Infrastructure instance, shared by
> WebCom, VisCom, SAC, Executive, etc.  This will allow us to easily
> interlink and collaborate on issues as required.
>
> Is there a way of creating a field to say which committee the ticket
> applies to, and then querying by that tag?
>
> Jason
>
> -----Original Message-----
> From: sac-bounces at lists.osgeo.org [mailto:sac-bounces at lists.osgeo.org]
> On Behalf Of Tyler Mitchell
> Sent: Monday, January 22, 2007 07:37
> To: System Administration Committee Discussion/OSGeo
> Subject: Re: [SAC] Subversion is 403 right now
>
> Are you actively making changes to the Trac architecture or restarting
> it, etc?  Or can we start to use an instance of it for WebCom, SAC
> issues now?
>
> Tyler
>
> On 22-Jan-07, at 5:57 AM, shawn barnes wrote:
>
>> Fixed for now.
>>
>> my apologies...i had a rule to rewrite svn.osgeo.org to a 403 i had
>> tested to see if you could still svn.osgeo.org/svn/project but, i
>> guess i was really testing my browsers cache.
>>
>> So consensus is virtual host for svn.osgeo.org?
>>
>> trac is installed and i'm currently working on importing fdo and
>> mapguide bugs from cn into trac.  this is taking a little longer than
>> i had hoped as the cn's bug/artifact tracker is quite different than
>> trac.
>>
>>
>>
>> shawn
>>
>> Howard Butler wrote:
>>>
>>> On Jan 21, 2007, at 2:43 PM, Jason Birch wrote:
>>>
>>>> I think that it should be re-enabled, at least long enough to  
>>>> switch
>
>>>> the sites over to SSL.
>>>>
>>>> However, I think a better solution would be to make svn.osgeo.org
>>>> its own virtual server, rather than relying on an alias within
>>>> www.osgeo.org.  This would have the desired results without
>>>> requiring any client-side changes.
>>>>
>>>> If we have multiple sites that answer for the content at
>>>> www.osgeo.org, there's a strong possibility of being penalised by
>>>> the search engines.  A large part of OSGeo's role is marketing, and
>>>> search engine ranking is important.
>>>
>>> Understood.  Another big part of OSGeo is actually writing the
>>> software ;)
>>>
>>>
>>>>
>>>> Does SVN require an account on the server?  If so, isn't it more
>>>> secure to require SSL?
>>>>
>>>
>>> SVN requires an LDAP account to be able to commit to the repository.
>>> Ideally, we allow anonymous (http) checkout and read access and
>>> authenticated (https) commit access.  If you are a committer, you
>>> should be working with an https repository.  I think that CN just
>>> always used https to eliminate the ambiguity.  It isn't a problem to
>>> switch between http and https if you are committer and can actually
>>> read both repositories though.
>>>
>>> +1 on a true virtual server for svn.osgeo.org
>>>
>>> This would allow us to additionally drop the redundant /svn path on
>>> everything...
>>> http://svn.osgeo.org/svn/gdal could just turn into
>>> http://svn.osgeo.org/gdal
>>>
>>> I don't know where we're at with Trac, but was the intention to use
>>> virtual servers there too?  Shawn?
>>>
>>> Howard
>>> _______________________________________________
>>> Sac mailing list
>>> Sac at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/sac
>>>
>>
>> _______________________________________________
>> Sac mailing list
>> Sac at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/sac
>
> _______________________________________________
> Sac mailing list
> Sac at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/sac
> _______________________________________________
> Sac mailing list
> Sac at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/sac



More information about the Sac mailing list