harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [classlib] Preprocessor - CHECKPOINT
Date Thu, 02 Nov 2006 19:44:26 GMT


Etienne Gagnon wrote:

[SNIP]

> 
> Such changes are usually not dealt with very neatly with "svn merge".

I'm confused.  I don't think anyone has suggested that we use "svn 
merge" for this.

> Now, if using the processign tool, you get at least 2 benefits over "svn
> merge":
> 1- No need to do any "svn merge"...  The method was moved AND renamed
> even for j2se6.
> 2- You were aware, when moving the method and changing its name that you
> could possibly be making the life of j2se6 developers a little more
> difficult.
> 

Right - that's how I thought it would work.

> The "communication" aspect of 2 can be quite helpful when doing
> system-wide changes.  Just think about the effect of simply doing a
> system-wide reindentation of source code; this is a nightmare when
> developing using branches, as diff/merge tools are line-based, not
> syntax-based.  So, if your new indenter moves things across lines,
> you're in hell.
> 

So here's where I'm starting to believe I'm missing something important :

Can you give me an example of the "communication" that you imagine 
taking place here?  That's the part I'm just not grokking here.

> Believe me; I've lived through that trying to maintain a "well indented"
> GNU Classpath in SableVM's repository.
> 
> I am not saying that using the tool should replace using branches for
> all situations, but there are situations where it would be more
> effective not to use branches when the code is mostly identical.  

I want to avoid branches at all costs.

> Using
> traditional pre-processing tools, in such cases, is often the solution
> adopted by some people; the problems of "simply-mided" traditiona
> pre-processing has been discussed earlier in this thread.  I am
> proposing, instead, to use an innovative "syntax-based, revertable
> processing".  That's all.  [I guess you'll need to see it working to
> make sense of it...  I'll work on a prototype.  I've just submitted the
> ICLA/ACQ].

Syntax based is fine - we never settled on what kind of pre-processing 
scheme we would use, so whatever seems best, go for it.

Clearly there's some confusion here.  My goal is to

1) Avoid branches at all costs so we can share as much code, and get as 
much benefit for collaboration between different versions, and different 
platforms, if that happens.

2) make it simple to work in either the 'master' code, or the 'target' 
code through tooling, including standard IDE activities like debugging

3) make it easy for users to report bugs based on 'target' code, 
including patches and line numbers

Now, maybe I'm misunderstanding you, but it sounds like your approach is 
one-way, and coarse grained.

What I've suggested is  :

   forward(X, platform) -> Y

   reverse(X, platform, Y') -> X'

for X being a single class.  To produce a complete target source base, 
walk the single source tree as defined by a 'platform descriptor' :

   foreach(file in descriptor) {
      forward(X, platform);
   }

so for a  source tree

  master/
      dir1/
        X1
        X2
      dir2/
        X3
        X4

and a platform descriptor

  java5/
      dir1/
        X1
      dir2/
        X4

then walking the tree gets us :

   java5/
      dir1/
        Y1
      dir2/
        Y4


Does this match your model?  If not, what's different?  I admit the 
above is simple minded.  I can imagine many, many messy corner cases. 
But it's a reasonable starting point?  I'd like to setup this 'master' 
tree in the sandbox.  Can anyone suggest any good examples of diffs 
between java 5 and java 6 so we can put diffs in the classes X1-4, or 
have paltform unique classes in X1-4?

geir



Mime
View raw message