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. 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). 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.] The idea is that manual processing is never required when coding using canonical and dev-target modes. No inexact modifications, no difficult merges, etc. 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? :-) Etienne -- Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/
signature.asc
Description: OpenPGP digital signature
