Etienne Gagnon wrote: > Geir Magnusson Jr. wrote: >>> To release code, one would apply: >>> >>> process(X, release-target) => Y >>> >>> Now, it is important to understand that Y, in this case, is NOT suitable >>> for doing any modification as >>> >>> revert(Y) => Kaboom! (The tool will simply report that it can't do it; >>> it won't crash.) >>> ... >> This is what I thought we were talking about all along - basically >> starting w/ the full source, and pre-process to the "canonical" source >> for the target version. >> >> However, I don't understand why I can't go backwards, modulo some manual >> merging if needed. >> >> For example, if I have X and release-version, I should be able to take a >> Y' and resolve back to X'. There are problematic cases. [...] > > It's the problematic cases I am trying to get entirely rid of "by > design", by having an "exact" transformation process, in contrast with > the usual branch/merge "inexact" process.
Yes, this is the key point for me, that the transforms are exactly reversible so you loose nothing by switching back and forth. > Of course, this means that development happens using "complete" source > code (this is either the canonical form or a development target form, > but not a release form). Ack, and I agree with the comment made elsewhere that it is useful for each processed form's developer to see their changes in the context of all potential processed forms. > For applying user-provided patches, then it can still be done the good > old way, using these "little" patches made from release code, but > applying them directly to the canonical or dev-target code, resolving > conflicts manually. [The smaller the patch, the easier it is to apply > it on files with target-specific code.] How so? With a customized patch tool? Because the end-user's patch will have line numbers relative to the 'releasetarget' code. > The idea is that manual processing is never required when coding using > canonical and dev-target modes. No inexact modifications, no difficult > merges, etc. Hurray. > And, as a bonus, communication between parrallel target > developers. I know, it's an "unusual" development processing tool, but, > hey, why shouldn't Harmony innovate? :-) ...continue to innovate ;-) Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
