Tim Ellison wrote:
Geir Magnusson Jr. wrote:
Because I can imagine that as a SE programmer, I would want 1 of 2 things :
1) clean code to work on for a specific target (say SE 5)
2) a hybrid version of your dev1 that only has the glop for a subset of
the platforms (say just Java SE 5 and Java SE 6) in it, so I can focus
across just those two.
Maybe it's just me, but I'd probably want the distractions of other
platforms out of the code so I can get better into the 'flow' when
developing.
So that's why I think of dev1/2/3 as being the virtual code (not key to
the process) that can be generated either by the tooling onto disk as a
temp form, or by IDE virtually in situ.
but how do you resolve the ambiguity of where new/moved code should go
in the master if you are working in a dev that has lost the context of
other streams?
I want to make sure I understand what you are asking - I think you are
asking the question "As a developer, if I can't see the content of the
other streams, how can I place the changes in context of the other streams?"
It's not clear to me that there's a big problem here - the fact that a
complete master exists means that when you "commit" your changes to the
master, you can resolve ambiguities in placement relative to other
streams at that time, *if* there are any. (For the life of me, I can't
figure out how to mechanically characterize an ambiguity...)
The big question here is if that's a reasonable approach, and the answer
will be based on how often it happens.
If it happens in 1 in 50 "commits", I'd argue that the benefit of the
reduction of clutter is worth it. If it happens every time, it's
clearly going to be a royal PITA. I don't know actually where to draw
that line. I expect testing with toy examples will help us figure it out.
it's the point that was made here:
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200611.mbox/[EMAIL
PROTECTED]
I went back and review that, and I keep getting this nagging feeling
that we're being a bit naive about this, but I can't put my finger on it
and explain why :) I'll try to explain in a separate post.
it would be cool if we could do that.
Yes - my goal here is to make this as transparent as possible to the
working harmony developer.
Further, there aren't just N dev forms for the N distinct
platforms/version, but rather the freedom for combinations where they
make sense (a dev w/ SE 6 and SE 6 only)
If you want to generate a dev1 and work on that on disk, great - do it,
you can go back to master.
Only if the reverse mapping is exact, which I believe means that you
need to take the full master context along with you.
I don't believe so. I need to do some tests. The reason I don't believe
so simply because the master context exists in the master (by defn),
which always is a part of the "commit" process - IOW, when committing a
dev1' (modified dev1), you can regenerate the clean original dev1 from
master, then find your diffs to that from dev1' (the modified thing you
are committing), and map those back into the master.
I think.
[SNIP]
Or in simpler terms, the model differences seem to boil down to this.
Given N possible targets:
1) Master is concrete, dev1..M (where M possibly > N) are generated
simply for ease of use either as concrete tree on disk or virtually in IDE
2) Master is virtual, dev1..N are concrete, one dev form is Most Favored
Nation Status so something coherent can be shoved into SVN (Q: is MFNS
necessary? Nice, yes, but necessary?)
Yes, that seems to be the difference. I'd like to be convinced that
working in dev1..M code is possible in approach (1).
Yes, and I can almost prove now that not having a master is unworkable,
because we're not talking only about file content, but different files,
and different directory structure. So if the classlib code spans both
versions (SE 5, SE 6) as well as platforms (ME, SE), the build process
will require processing to deal with that during the build. if that's
the case, then you are in case 1), not 2).
I'm going to try to cough up some simple use-cases of code trees and
toss in the sandbox.
geir
