Tim Ellison wrote:
Geir Magnusson Jr. wrote:
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.
I believe that there will still be a role for branches, both for
sandboxes to experiment as Etienne said, and for the maintenance streams
of our releases.
Of course we aren't going to ban branches. The context is branching for
mainline code. Lets stay focused...
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.
Agreed -- our src.jar will be 'normal' Java code without multi-target
mark-ups.
<snip>
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.
There are multiple 'devtarget's -- each contains all the source code
marked-up for every target being developed, but each is distinct by
having different targets uncommented. Since each devtarget contains the
entire source code it is possible to accurately transform from any one
devtarget to any other devtarget. One of the devtargets is actually
stored in svn, and that is the canonical form of the devtarget code.
So that's 'master'. and everythign else is a transformed master, right?
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.
Screech -- the releasetarget, by definition, does not contain the source
for all possible targets so that it is consumable by end-users.
That is correct.
The only code that contains all code is master.
So what to do with a patch?
I can either
patch -p0 << reverse(patch.file)
I don't understand how you will ensure there is enough information in
patch.file to make the reverse() function exact? I proposed that our
releasetarget code contains tie-points where it is out of sync with the
closest devtarget by some number of lines.
I don't understand why you'd bother. If you know that patch P creates
Y' from a given Y, and you can always create Y as you know everything to
do the xform from master source and the platform name, everything is known.
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?
It's all one proposal. Etienne's principal idea with a few others
meddling on the side :-)
Regards,
Tim
