[os-infrastructure] svn and piccolo

[Bodo Bergmann]

Has there been made any try to have piccolo set up in a way  to get
really comparable performance results?
Topics I have in mind are:
- Modern hardware/OS (usilsuxx is "outdated" - it still has the "For CA
only" pre-login information)
- Only the a current codeline (not the big history)
 
The hardware/OS can have a huge impact on processing time,
e.g. for doing a daily build for OpenROAD it takes:
- On Linux (using a VM within WindowsXP machine, located in Germany) : 8
min
- On Solaris (using a machine in Redwood City) : 2:10 hours
 
I could imagine, that the Piccolo processes and DBMS could show similar
behaviour
(in addition to the network issues).
 
Bodo.

________________________________

From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Alex Hanshaw
Sent: Friday, May 23, 2008 10:20 AM
To: Discussions about the infrastructure needed to support a true
opensourcecommunity
Cc: David Reed; Robert Kibble
Subject: RE: [os-infrastructure] svn and piccolo



Hi Steve

 

 This is consistently 1 hour in the UK,. My pull was to a linux desktop.
Ray has had similar download times.

I don't the speed of a full code line download should be a deciding
factor. There is no need to pull a

full code line on a day to day basis.

 

 Alex

 

 

________________________________

From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Stephen Ball
Sent: 23 May 2008 06:08
To: Discussions about the infrastructure needed to support a true
opensourcecommunity
Cc: David Reed; Robert Kibble
Subject: RE: [os-infrastructure] svn and piccolo

 

I'm in Australia at home (which is about as far away from the SVN server
as you can get), but and it takes less than 10 minutes for me to pull
subversion onto a Linux client; I have repeated this exercise at least
10 times and it is fairly consistent....is there something up with the
U.K. link? Are you running Windows and having an issue with the windows
svn client?

 

Steve

 

From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Alex Hanshaw
Sent: Friday, May 23, 2008 12:23 AM
To: Discussions about the infrastructure needed to support a true
opensourcecommunity
Cc: David Reed; Robert Kibble
Subject: RE: [os-infrastructure] svn and piccolo

 

Hi Bruce

 

 Piccolo is throttled on the network, svn is not.

 Svn took over an hour to come down in the uk, vs 5 minutes for Andrew.

 

 There may be a problem in setting up the OpenRoad community repository
given the code is shares from

different versions of Ingres. Some discussion with Andrew may be
required.

 

 Alex

 

________________________________

From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Bruce A. Lunsford
Sent: 22 May 2008 15:17
To: Discussions about the infrastructure needed to support a true
opensourcecommunity
Cc: David Reed; Robert Kibble
Subject: RE: [os-infrastructure] svn and piccolo

 

Sounds good to me, particularly if the syncing of piccolo-opensrc and
svn is automated, which it seems like it could be.  One other advantage
is that we don't lose the history in piccolo by a 1-time switchover to
svn (or alternatively have to come up with a way to get the history
migrated to svn).  One downside is that I was really enjoying the
under-10-minute refresh of an entire source build area using svn as
opposed to 8 hours or so with piccolo (which is why "p need" will
continue to be the favored approach with piccolo versus blowing away a
build area and starting from scratch).

 

>From the perspective of EDBC, this approach also helps because the EDBC
server code is now at the point of being put into piccolo.  This was
never possible before because of the lack of a piccolo mainframe client,
which was recently completed.  Moving to another CM system would have
meant porting another CM client to the mainframe (or sticking with
piccolo).


Regards,

 

Bruce

 

________________________________

From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Alex Hanshaw
Sent: Thursday, May 22, 2008 3:49 AM
To: opensource-infrastructure at lists.ingres.com
Cc: David Reed; Robert Kibble
Subject: [os-infrastructure] svn and piccolo

 

Hi all

 

 Robert Kibble today suggested a rather neat solution to our svn and
piccolo dilemma.

 

 The idea is that we create a piccolo branch off of main that is
identical and kept in tight lock step with

the svn repository.

 

 Every submission in the svn repository could then be replicated in the
piccolo-opensrc branch with a file

copy of the affected files. No need to merge difs.

 Every change in the svn repository could then be easily integrated into
main through the use of an ineed against

the piccolo-opensrc branch.

 Any change in main that we wished to push through into the svn
repository could be done by locking the affected

files in the svn repository at head rev, crossing the change from main
into the piccolo-opensrc branch (identical

at head rev to svn) and then whole file copy the piccolo-opensrc files
to the svn repository for submission.

 

 By forcing a tight lockstep of the svn repository and the
piccolo-opensrc branch replicating the changes between

the two repositories would be as simple as copying files.

 

 If we adopt this approach:

1)       We have zero disruption to our paying customers.

2)       We can provide a community codeline using svn.

3)       We can easily pull changes between the community repository and
our piccolo repository.

4)       No need to rewrite existing scripts and procedures built on and
around piccolo.

5)       Significantly reduced svn training costs.

6)       Ingres staff wanting to contribute to the community edition can
working in svn or piccolo (removes the barrier of not knowing svn).

 

 Let me know what you think.

 

 Regards

 

 Alex

 

 

  

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ingres.com/pipermail/opensource-infrastructure/attachments/20080523/8bfd8aad/attachment-0001.html