Etienne Gagnon wrote:
Geir Magnusson Jr. wrote:
[...]
See, I'm hoping for something a tad different :
1) For building : process() (and revert() for fun) for cmd line use for
the build scripts, so we just do
...
2) For development : IDE plugin where
a) I can tell plugin that my project def/configuration is whatever,
it using metadata in a file, only consider the code that is
defined (or not excluded - whatever is easier)
b) I can tell plugin to look at X, know that I want
"java5" and in situ, it shows me what Z would look like.
I edit this, but I'm really editing X. And I want to
be sure, I push a button or have a split screen that
shows me what X really looks like.
I can edit in X, or in "virtual Z", or both at the same
time, as I'm just really editing X.
I have nothing against this! But, we have to make sure:
1- we don't lose the "communication" aspect of telling developers about
parrallel development.
I'm not sure I understand what problem you are trying to solve there.
We do parallel development on the source base right now - no one ever
does a blocking checkout - it's optimistic.
2- we have a robust "language" design; this is best achieved by first
building the command-line based tool, then extend it into a full-blown
Eclipse plugin... :-)
Right. The fact it's the same basic transformation code and process.
The fact that someone embedded it in eclipse doesn't change the
fundamental process.
geir
Etienne
