[os-infrastructure] State of the onion

[Alex Hanshaw]

Hi Joe

A tag is a copy. If you pull the take and make changes you create a
branch.
So it's not possible to pull a build to a level that reproduces a
problem and submit a change in that build. Once a fix is identified a
separate checkout from the actual code line has to be pulled and the
change merged from the tag-checkout into the new build (where you can
not confirm that
intermediate changes have not invalidation the code solution in some
way).

 Alex

-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Joe Abbate
Sent: 06 June 2008 15:09
To: Discussions about the infrastructure needed to support a true open
sourcecommunity
Subject: Re: [os-infrastructure] State of the onion

Alex Hanshaw wrote:
>  I understand your frustration about not being able to go all out svn.
> However, to use your phone analogy, svn is missing the bits that allow
> you to talk down the line. If you want to spend all day doing morse
code
> because that's all the open source world has available . . . .
>  Not having labels is an inconvenience, we could probably manage but
> would have to pull a separate build to do any updates to avoid
branching
> the TAG.
>   

As Mike, I was only told about this mailing list a week ago, and I 
haven't finished reading the archives, but IMO an svn "tag" is 
functionally equivalent to a Piccolo label. I had a chat on IRC with J 
about this earlier and he seemed to agree with me.

>  The real show stopper in my opinion is svn's woeful inability to
merge
> to
> code changes without manual intervention. No one on this list has said
> they
> have had a different experience. From the web it is a common criticism
> of svn. With the number of cross integrations SE do (which will
increase
> with more frequent release schedules) we are back to the morse code
> analogy.
>   

The merge history tracking is indeed a major issue and I haven't used 
svn 1.5rc so I can't tell how close it will come to Piccolo's 
capabilities. From what I know, svn commit log messages are the only 
"tool" for keeping track of what has been merged. OTOH, svn allows you 
to merge across branches, i.e., you can merge a changeset from 
ingres2006r2 to ingres2006r3, without merging it into main first. Note: 
although Piccolo can tell you what changes need to be cross-integrated 
prior to the integration, a change itself doesn't show what change is 
its "parent", unless the engineer chooses to show it in the description.

>  The long term goal should be to move to svn across the board. When
svn
> comes up to scratch. In the mean time we can try to enjoy the best of
> both worlds. Remember svn can still be used to foster a community with
> us
> using piccolo for internal code lines. That's the objective. Using svn
> is not an objective.
>   

I agree with most of the above. I think Subversion could be used for the

main codeline, but Piccolo will have to remain in use for other 
codelines. Furthermore, there is no svn client for VMS and trying to use

some remote alternatives (Andrew suggested SVNkit) would be inconvenient

to say the least. Mercurial shows promise (although I haven't actually 
tried it on VMS), because it provides svn import/export functionality.

Joe
_______________________________________________
opensource-infrastructure mailing list
opensource-infrastructure at lists.ingres.com
http://lists.ingres.com/mailman/listinfo/opensource-infrastructure