[os-infrastructure] Model discussion boiled down

[Joe Abbate]

Hi J,

Jay Hankinson wrote:
> 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.

That's why I have argued, almost from the inception of the 
client!subversion client.template, that we should simplify and get of 
rid of all the mappings and fmappings, so the typical Piccolo map will 
be almost a direct reflection of the source tree on the build area and 
the client.map can then be something as simple as:

map ingres YOUR_CLIENT ingres!community!ingres!%1   YOUR_TRUNK/src/%1
map ingres YOUR_CLIENT ingres!community!ingres!%1!%2   YOUR_TRUNK/src/%1/%2
map ingres YOUR_CLIENT ingres!community!ingres!%1!%2!%3   
YOUR_TRUNK/src/%1/%2/%3
map ingres YOUR_CLIENT ingres!community!ingres!%1!%2!%3!%4   
YOUR_TRUNK/src/%1/%2/%3/%4

 From what I've been reading, the OpenROAD client.map will still need to 
be more complicated, but that's something that can be worked on, without 
modifying Piccolo itself.

>
> 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)

Trac does have support for other RCSs, so I'm guessing it wouldn't be 
too difficult to plug Piccolo in.

>
> - Make client stateless

This is probably the biggie. I would be interested in knowing if 
Perforce has stateless clients.

>    - 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

A simple solution would be to allow "p get --readonly" (or "p fetch") 
where Piccolo won't keep track of what you download.  For commit access, 
you would have to use the normal "p get" or we would need a "p 
subscribe" option to let the server know about the intent to work on a 
particular directory.

>
>    - You currently need to be connected to the server to do anything. 
> open, rcompare etc.

"Need to be connected" gives the impression that you need a permanent 
continuous connection, which is not the case.

>
> - Generally improve performance and stability
> - Universal diff output

I would think this isn't that diff-icult since the clients can plug in 
to the local diff command (DIFFERENCES on VMS) or request a -s for a 
diff on the server.

Joe