[os-infrastructure] State of the onion

[Joe Abbate]

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