Merging branches? (was: Port helper libs to 3.5)

[GoogleCodeExporter]

Port helper libs to 3.5

Original issue reported on code.google.com by phil.qui...@gmail.com on 2 Apr 2009 at 10:09

[GoogleCodeExporter]

To level-set, I ran the tests against 3.5 a few weeks back and, amazingly, they
passed!  The question this provokes is whether we want to do a port/branch at 
all. 
I've groused about maintaining branches elsewhere
(http://code.google.com/p/wt-commons/source/detail?r=214) and moving forward 
I'd like
to think hard before we do another branch.

Original comment by phil.qui...@gmail.com on 7 May 2009 at 9:05

[GoogleCodeExporter]

Upping the priority since this should really get resolved before Eclipse 3.5 
ships.

Original comment by phil.qui...@gmail.com on 7 May 2009 at 9:07

• Added labels: Priority-High
• Removed labels: Priority-Low

[GoogleCodeExporter]

"One source to rule them all, one source to find them, one source to bring them 
all
and in the darkness bind them..."

After back-porting a host of minor fixes to the 3.3 branch, I'm really keen to
reconsider our branching strategy.  The rub is I'm not seeing a deep reason for
distinct branches.  The differences between the 3.3 and 3.4 branches are not
substantial and are GREATLY outweighed by the similarities.  Moreover, there 
are no
places where pre-processing or reflection would be required in a merge.  
Finally,
moving forward, the fact that the 3.4 helper tests ran green out of the box for 
3.5
only strengthens my conviction.

Certainly some thought would have to go into handling cases where new helper
functionality is not relevant for old Eclipse platforms.  In the simplest case I
think documentation will suffice.  In case new additions require references to 
bits
that don't exist in earlier eclipse versions we could consider extracting these
dependent pieces out into fragments but we can cross that bridge when we get to 
it.

I'm sure there's more to consider but this is where I'm at after nearly going 
blind
staring at the diff/merge editor.

Original comment by phil.qui...@gmail.com on 7 May 2009 at 10:41

• Changed title: Merging branches? (was: Port helper libs to 3.5)

[GoogleCodeExporter]

Original comment by phil.qui...@gmail.com on 8 May 2009 at 10:33

• Changed state: Started

[GoogleCodeExporter]

r229 wraps up the first cut of a merge.  I chose to do this in the 3.4 branch 
for
simplicity (and to preserve SVN revision history).  Ultimately I'd like to do 
away
with the eclipse33 and eclipse34 subdirectories and move the merged branch 
somewhere
else.  (We can certainly archive 33 if you want to keep it around during the
transition; just let me know about that.)  Anyway, anticipating a likely need to
branch for e4 we might consider something like:

helpers/e3/...

The tests ran green for me on 3.3 and 3.4 so I feel good about this first cut.  
If
you want to review the revisions you'll see how little conditional logic there 
was in
the end.

Original comment by phil.qui...@gmail.com on 11 May 2009 at 8:49

[GoogleCodeExporter]

Cool! 

RE: eclipse33. I can still see a use for them down the line -- Let's go ahead 
and
nuke eclipse33 and eclipse34 trees and create /trunk/helper-libs/eclipse/. In 
this
directory we can put plugins/ and features/. When/if we need fragments, they 
can be
put into /trunk/helper-libs/eclipse33/. What do you think?

Original comment by jhouston.mail@gmail.com on 11 May 2009 at 9:31

[GoogleCodeExporter]

Sounds great.

I moved the eclipse34/ branch to eclipse/.  I'll leave eclipse33 alone for now 
in
case you want to do any sanity checking of the merge.  Feel free to blitz when 
you
feel comfortable (or give me the word and I will).

Original comment by phil.qui...@gmail.com on 11 May 2009 at 10:55

[GoogleCodeExporter]

Looks good. Can you go ahead and delete eclipse33?

Original comment by jhouston.mail@gmail.com on 14 May 2009 at 1:05