Etienne Gagnon wrote:
Geir Magnusson Jr. wrote:
[...]
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?)
I definitely think that it is necessary (where J2SE5 is the preferred
devtarget), at least during the initial transition to using the
processing tool.
:)
That still makes it "nice" - because you can always transform the SVN
tree to any platform anyway.
It's (I think) the least intrusive method for starting to slowly add
non-J2SE5 code in the development trunk while letting existing J2SE5
developers continue developing without changing the way they've been
using up to now.
Yep. "nice".
By leaving the preferred devtarget in svn, the hordes of existing J2SE
developers will have the choice of continuing to use simple "svn co/ci"
to work on the code and won't have to learn to use new, yet not fully
tested tools.
Yep. "nice" :)
It also lets the smaller number of non-J2SE5 developers test the
processing tools and help identify bugs (what!? :-P) and usability
problems without forcing J2SE developers into doing the same.
Maybe, in the longer term, it would make sense to have some kind of
canonical "master" form, and store that in svn, but I am a big fan of
the least disturbance path, when trying to put in place new processes in
an ongoing development project. :-)
Question: What would be the advantage (in the longer term) of putting,
in the Subversion trunk, source code in non-compilable canonical master
form, instead of compilable preferred devtarget form? Why is the
existence of "master" so important to you?
I need to go check if where I said it wasn't to be compilable, as I
don't believe I ever mandated that. I do think it's going to be
difficult to achieve though.
I think we both agree that we need a complete, fixed reference point to
put in SVN. (In that sense, you actually have a master too, actually)
However, it's not clear to me that a master can actually be created that
is complete for all platforms while still buildable directly w/o
transforms and look-aside hiding/moving as part of the build process.
If you need to transform and move things around while building, then you
don't have the model you are advocating. You actually have the concrete
master model. You could cheat, and have both the concrete master tree
and a preferred platform transform checked in at the same time, but
that's just the concrete master model with a convenient "generated
artifact" checkin as well. That's fine, as long as you remember to
update both and checkin both on modification. We do that for the
website, for example.
Even if we are astoundingly lucky, and we can create a simple buildable
tree that can magically be transformed across platforms, I think that
not distinguishing a master form as distinct from other forms is a
mistake, because for the case of wanting a subset of representation for
clarity in development (which I'm not sure you acknowledge yet is
important), transforms are irreversible w/o a fixed master :
masterToDev(master, 2+3, clean) -> dev2+3
meaning, transform master to contain code for platforms 2 and 3 only (ex
Java SE 5 and 6), cleaning out all other, compilable for 2 but including
3 material in comment form.
Then that is no longer a peer to your dev1/2/3 set (where all info is in
all forms, just compilable on different platforms) but different because
data for all platforms except 2 and 3 were taken out.
Therefore, I do think we need an explicit master copy, with the dev
forms as intermediate convenience in whatever forms the developers
choose to put them in (with all other stuff, subset of other stuff, w/o
any other stuff...)
As fun as this discussion is, it's all theoretical. I've never worked
with multi-platform java code. I've worked with a lot of multi-platform
C code, and having the ability to ditch the confusing #ifdef cruft for
the platforms I'm not working on at the moment would be a very
innovative and pleasant advancement. Anyway, this is theory. The real
test will be how it actually evolves in code...
geir
