[os-infrastructure] svn and piccolo
Stephen Ball
Stephen.Ball at ingres.com
Thu May 22 22:16:26 PDT 2008
As Andrew said, the idea to branch piccolo and lock-step with SVN was
one of the early suggestions. I absolutely think it is the right way to
go if we want to try to keep the repositories in-step short-term.
I will note that there can still be conflicts with this if we use a
multi-master bi-directional copy (someone updates a Piccolo file and
someone else updates the same file in SVN on the same day); so we do
have to have a way of dealing with that.
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:43 AM
To: Discussions about the infrastructure needed to support a true
opensourcecommunity
Cc: David Reed; Robert Kibble
Subject: RE: [os-infrastructure] svn and piccolo
Piccolo would keep track of what has or has not been integrated between
the piccolo-opensource branch and main.
There would be no need to track what has been moved between an svn
repository and it's equivalent piccolo branch because
They would always be kept in lock step.
I'd still argue the case for a single issue tracking system and given
that Service Desk is not linked at all to piccolo
or BUGs retaining piccolo would not make life worse if a unified issue
tracking system were used and it was not
hooked into piccolo or BUGs. Of course some will still argue the need
for separate systems to differentiate the
service supplied to paying and community users. I refuse to accept that
any of our paying customers are paying
so that they can be the privileged ones that get to use Service Desk. If
we clearly describe the differences of
paid and community support in actual terms of the support given the
issue tracking system should not affect
our customers decision to use paid vs community support.
We have web access to BUGs information on newbream. We could expose this
externally to have a single BUGs
repository. We could just let the community log issues as our paying
customers do. Paying customers do not log bugs
so do community users need to be able log bugs, or could they browse a
knowledge base in the same way as
paying customers? Perhaps restricted to content generated from community
issues?
No one has defined the difference between community support and paid
support. Until they do we shouldn't be making any
decisions about the implementation.
Alex
________________________________
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Andrew Ross
Sent: 22 May 2008 15:22
To: Discussions about the infrastructure needed to support a true
opensourcecommunity
Cc: David Reed; Robert Kibble
Subject: RE: [os-infrastructure] svn and piccolo
Hi Alex,
We talked about doing this early on, and I agree if we want to maintain
two systems, it is definitely the way to do it. Also, I think we're
going to need to do this in the short term regardless.
As time progresses, we'll be maintaining branches in piccolo and svn for
each release. This paradigm does accomplish many of the missing
capabilities such as public bug tracking, public code repository, etc.
However, it may be a bit more expensive in terms of complexity,
infrastructure, keeping track of what's been propped where, and training
than maintaining one system. There were a number of people who expressed
the opinion that we should not do this at the summit as they felt the
cost would be prohibitive.
It is still early in the analysis, but it looks like we have no silver
bullet to do per-platform patching for maintenance. What is your feeling
at this point regarding which is least painful... maintaining two
systems, or headrev patching while the codeline is in maintenance?
Andrew
________________________________
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Alex Hanshaw
Sent: May 22, 2008 6: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/820eac83/attachment-0001.html
More information about the opensource-infrastructure
mailing list