Geir Magnusson Jr. wrote: >> 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.
How about: j2se5 developers, seeing that his planned modification to
some code will lead to utterly broken nearby j2se6 (commented) code
fragments, steps on this mailing list and asks j2se6 developers to help
him find the most harmless way to do the change (or, at least,warn them
about the problem)?
>> 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.
[somewhat off-topic] I think that we should consider tools/approaches
on their merit. Sometimes, branches are the right solution... You
wouldn't want to use syntax-processing instead of branches for managing
sandboxes. ;-)
> 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.
Agreed.
> 2) make it simple to work in either the 'master' code, or the 'target'
> code through tooling, including standard IDE activities like debugging
Agreed.
>
> 3) make it easy for users to report bugs based on 'target' code,
> including patches and line numbers
Ah! That's something to add to my requirements. Fine! I hadn't
included the "patches" thing into account. It doesn't break what I've
exposed so far; it simply adds to it.
> What I've suggested is :
>
> forward(X, platform) -> Y
>
> reverse(X, platform, Y') -> X'
OK. I see this in *addition* to:
forward(X, devtarget) -> Y
reverse(Y') -> X'
So, to simplify the discussion, let's rewrite your proposal as:
forward(X, releasetarget) -> Y
reverse(Y',X,releasetarget) ~~> X' (possibly reporting
conflicts/problems)
That's neat. I like it. Yet, we would encourage developers to work and
submit patches using devtarget code, instead of releasetarget code.
In other words, here's how I see the distribution(s):
- Binary j2se5 Harmony release: includes j2se5release src.jar for
end-developers using debuggers to step through API code.
- Source j2se5 Harmony release: API are in j2se5dev form. The build
process uses the processing tool to generate j2se5release src.jar.
- Binary j2se6 Harmony release: includes j2se6release src.jar for
end-developers using debuggers to step through API code.
- Source j2se5 Harmony release: API are in j2se6dev form. The build
process uses the processing tool to generate j2se6release src.jar.
Why? Because reverse works much better with devtarget than
releasetarget code, and the communications benefit of devtarget that are
lost in releasetarget code (because of stream code erasure). In
addition, using smart IDEs, there wouldn't be much difference for
developers between the "visible" formats of dev vs release code when
working on it.
> for X being a single class. To produce a complete target source base,
> walk the single source tree as defined by a 'platform descriptor' :
I don't really understand the "platform descriptor" thing, yet I think
that it is, somehow, an orthogonal issue to the discussion above.
[Remember my long message describing 2 levels of processing:
file/directory-level and source-level.] My first prototype tool would
attack source-level processing (discussed above), to validate the approach.
Maybe you could try rephrasing your file/directory-level (right?)
proposal? How does it differ from Tim's proposal?
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
signature.asc
Description: OpenPGP digital signature
