Geir Magnusson Jr. wrote: > One copy (the master) on which the IDE and cmd line tooling does both > the "file/directory" masking (dealing with the differences that aren't > just in class files - add and remove classes, etc - the "lookaside > table") as well as code xform. > > I never thought of having that intermediate form (dev1/2/3) as being > fundamental to the model, although it's a nice option. I can see how it > will be nice for editing, but I'm instinctively suspicious of it being > necessary). > > Why? > > 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? it's the point that was made here: http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200611.mbox/[EMAIL PROTECTED] it would be cool if we could do that. > 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. > If you want to just work on the single master tree, you can do that if > the IDE has the tooling. > >> >> We also talked about how patches to the source that Mrs CLDC developer >> sees can be matched back to a devtarget. > > Yes, I did read it :) I was changing focus, you knew that <grr> > Thanks for the example. I guess the difference is that I virtualized > the dev1/2/3 form and used tooling to just let people work on master > directly, or let dev1/2/3 be concrete as a temporary form for > convenience, as I noted above. > > 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). Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
