Etienne Gagnon wrote:
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)?
Ok - we do that now. I thought you were saying that your tool added
somehow to communications.
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. ;-)
I'm trying to figure out the merit here.
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.
It has to be the case - we'll do snapshots and distributions of
"src.jar" and when a developer goes into the debugger, they need to see
normal Java SE 5 code.
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'
I believe that
reverse(X, palatform, Y') -> X'
is the same as
reverse(Y') -> X'
as you need to know at least what platform Y' is, and what it came from.
You could always embed as metadata in the code itself in a comment, I
suppose. I was just being explicit.
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.
I don't know this terminology. I was using "master" being the code in
SVN, and "target", being the code Y, so the map is :
master == devtarget
target == releasetarget
right? Ok.
I want to work in the master code w/ an IDE plugin that lets me think
I'm in target (and lets me flip back to master). No preprocessing of
the tree is required to develop.
However, end-users - people who take our JDK and work with it, will
report bugs with stacktraces and line numbers that are from
target/releasetarget code.
So what to do with a patch?
I can either
patch -p0 << reverse(patch.file)
on the main code or use patching facilities in an IDE to patch the
transform view
Man, this tooling is going to be fancy! :/
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.
Yes.
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.
I don't think it matters, as I think that most people interested in
working on the code will just check out of SVN.
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.
Right - the "platform descriptor" is the data that the
file/directory-level thing uses.
Maybe you could try rephrasing your file/directory-level (right?)
proposal? How does it differ from Tim's proposal?
I get lost in who's proposal is who's. I thought we were working
towards one collectively owned solution. can you describe what you
think Tim's, your's and mine are?
geir
