[os-infrastructure] Model discussion boiled down

[Jay Hankinson]

Roger L. Whitcomb wrote:
> J - what do you mean exactly by "Make client stateless"?  Are the two
> points under that what you mean by it?
>   
Currently the piccolo server is aware of the state of all piccolo 
client. For most scm systems this is not the case. The sub points I made 
were just to highlight some specific issues.
> So, you think (or do you know because you've analyzed it) that the
> "have" table updates are the main bottleneck that makes it so much
> slower than (say) subversion in pulling a source tree?!  Actually, by
> using the -p flag on "p get" the "have" table is not updated ..... This
> could be used to (maybe) speed things up and eliminate the bottleneck. 
>   
The performance issue with piccolo isn't really piccolo it's the network 
speed between Islandia and other offices. Pulling an entire client in 
Islandia take about 20 mins. This is still noticeably slower than svn. 
Maintaining the will obviously put some sort of break on initial full 
client pulls but it's not the main issue. The main problem we have is 
have table contention when running (and in particular piping) piccolo 
"query commands". Virtually command does a join on the have table and as 
I've said a few times on other lists, when commands are piped, the locks 
are not released until the second command finishes. This a real issue 
when doing a  p need | p get -l -

These contention issues can probably be resolved by updating the server 
to use functionality added after Ingres 5 ;-) but you still need to able 
to "see" the server to even start editing files it they're not already open.
>
> Roger Whitcomb | Architect, Engineering | Roger.Whitcomb at ingres.com |
> Ingres | 500 Arguello Street | Suite 200 | Redwood City | CA | 94063 |
> USA  +1 650-587-5596 | fax: +1 650-587-5550
>
> -----Original Message-----
> From: opensource-infrastructure-bounces at lists.ingres.com
> [mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
> Jay Hankinson
> Sent: Wednesday, June 25, 2008 4:18 PM
> To: Discussions about the infrastructure needed to support a true open
> sourcecommunity
> Subject: Re: [os-infrastructure] Model discussion boiled down
>
> I'm have to admit, I'm a little surprised this particular conversation
> is happening at all. We have huge job ahead to us to try build a
> community around Ingres and OpenROAD without forcing outside users to
> learn a completely new source code management system to do so. Having
> been piccolo development and support for the passed 7 years or so I can
> say without any hesitance, the biggest single issue I see from new users
> (and current for that matter) is grasping the concept of map files and
> subscription lists. It might work well in the well defined (and usually
> pre-setup) confines of our build environments but how many people on
> this list could setup a piccolo build environment from scratch? Even
> with all the critisim leveled at SVN (and I'm not a huge fan of it
> myself), I would hazard a guess there are more of you that could get
> going on subversion than piccolo. In my opinion it is just plain not
> suited for use in the environment we are trying to grow. Subversion may
> not the answer, but neither is piccolo.
>
> However, in the interests of fair and open discussion (and that is
> really what we need to focus on) here is the beginnings of a list of
> things that would need to be addressed in piccolo before it would be
> suitable for community use. Fell free to add to it (or dispute it for
> that matter).
>
> J
>
>  - Web client or at very least some sort of publicly readable access
>  - Proper user authentication for committing, probably over ssl
>  - Hooks into IDEs (at very least Eclipse and  OpenRoad)
>  - Hooks into a bugs tracking system (or you can add give bugs web
> access too)
>  - Make client stateless
>     - The repository currently holds every version of every file on
> every client ever created (and not unsubscribed). For ad-hoc public
> downloads this clearly won't scale. The "have" table in the database is
> the main source of contention
>     - You currently need to be connected to the server to do anything. 
> open, rcompare etc.
>  - Generally improve performance and stability
>  - Universal diff output
>
>
> Joe Abbate wrote:
>   
>> Hi Andrew,
>>
>> Andrew Ross wrote:
>>     
>>> At the moment, no one is signed up to develop piccolo to be 
>>> appropriate for community. If someone wants to fight for that great, 
>>> but let's be mindful of what else they could be doing other than 
>>> developing a tool we can easily get for free.
>>>       
>> I'm reminded of Heinlein's TANSTAAFL. Piccolo is already developed and
>>     
>
>   
>> is even "freer" than Subversion. We already have 50 or perhaps more 
>> developers that are familiar with Piccolo and all its quirks and 
>> nuances. Some have even gone as far as creating a layer of scripts 
>> that makes submissions and integrations easier or that pinpoint 
>> changes that have not been cross-integrated into a given codeline.
>>
>> I understand that external contributors may find Piccolo 
>> uncomfortable, but is that the only reason to discard it as a 
>> solution? Or what about its close cousin Perforce which can be used 
>> for free for open source projects? External contributors may also find
>>     
>
>   
>> Jam uncomfortable (like some of us do), but like it or not, it does 
>> work portably on the platforms we support.
>>
>> If we think Piccolo is not appropriate for community projects, why not
>>     
>
>   
>> start with a list of items that would make it appropriate?
>>
>> Joe
>> _______________________________________________
>> opensource-infrastructure mailing list 
>> opensource-infrastructure at lists.ingres.com
>> http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
>>     
>
> _______________________________________________
> opensource-infrastructure mailing list
> opensource-infrastructure at lists.ingres.com
> http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
> _______________________________________________
> opensource-infrastructure mailing list
> opensource-infrastructure at lists.ingres.com
> http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
>