My first Dada Mail CVS commit was an overhaul of the program's
default CSS template And because it was a major, structural
overhaul -- that is, not just a change of a line or two, but a
shuffling of large chunks of code -- Justin found it impossible to
merge his local-repository changes back into it, and ended up
having to rewrite them into my version as though he was working
from scratch

I think a lot of this had to do with the CVI gui software I was
using; any committs you were doing would mess me up completely -
which stinks, because my former CVS gui app had some great features
that jCVS doesn't touch;

And for argument's sake, let's say you want to put them all in a
subdirectory, /errors/, to keep things more organized Still no
problem; we're golden

But if you decide you'd also like to add subdirectories for / screens/ and /widgets/ to make things ever cleaner, and you want to
move the relevant current templates into these new subdirectories,
the only good time to do that would be before version 2 10 is
branched because otherwise, your changes won't merge well with
the 2 10 x bug-fix branch, and we'll have to do a bunch of manual
diffing & merging after the fact to get things back on the same page

I'm not sure if it's time for normalization of the template files; At
the moment, this is done losely by a naming convention, whole screens
end their name with, "screen tmpl", parts have, "widgets" in their
names - there's a few templates that break this convention, like
the css file I think - this is mostly so when I open that file up in
my text editor, everything's nice and color coded So I'm not sure if
I want to sit down and start to structure all the screens, in nice
little neat directories I needed a release out yesterday :)

The other problem may be performance; in code, the program will have
to look for each new directory we make to find the correct template -
say we have 4 separate directories for templates At the moment, I
think Dada Mail guesses four different places the template directory
could be - this would change into 16 searches, which may impact
performance - and the template performance is definitely a step
backward - you can see Dada Mail drawing the screen sometimes :)

As for the merge-hell in 2 11 from the 2 10 x that we'll be on - I'm
ready for it, although I do think that CVS will keep track of file
moves and apply the diff's, even if the file has changed physical
locations It sort of looks like CVS voodoo; I'm hoping jCVS can sort
of help in this

Does that make sense? Basically, what I'm thinking is that now that
you have a roadmap, I think it would be a good idea to imagine how
you want the program to be organized in the long term, and then to
make those structural changes, if any, now rather than (more
painfully) later

It does, but I'd like to hold off this until we get a new release
out, since currently, there's a version out of Dada Mail with 2 month
old bugs I need some breathing room before we start restructuring
If we restructure, we'll invite new bugs and that'll mean release
time gets pushed back

All I'm saying is that you should think about whether you know we
ever will have to and if the answer is yes, we should do it now
and save ourselves the extra branch-merging problems later

I say we wait until 2 11 development, since after 2 11, 2 12 will be
worked on, with a branched 2 11 x - and the cycle continues :) It'll
be a constant issue and one that's (hopefully) been thought through
by smarter people than me that we could use as a basis on how we do
things - I'm just ancy to get a release out

Justin Simoni