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
