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.
At what cost though? We are used to the inexact process now...
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).
What's the diff?
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.]
In which case we have the inexact process anyway.
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? :-)
I'm missing something then. You just said you can't go backwards.
There is only one file for class C in SVN. How do I work on anything
but that copy if there is no going backwards?
geir
