This duplicates data in both confluence and in SVN.
Confluence is bulky. Why bulk it up more with versioning code in flux with it. Subversion
does this better.
As we bounce around ideas in this volatile stage we may make several changes. And
for each change we have to maintain it in two places. Furthermore there's going to be
a perpetual synchronization problem.
What about this instead?
(1) comment code in the code and discuss things on the mailing list
(2) stabilize interfaces after several passes then commit to them
(3) remove the code from confluence and just reference the code in subversion
(4) remove @todo comments talking about design issues and use them to
compose the design documentation explaining these choices made
(5) use extra energy and time to organize better the developer documentation
on this and give synopsis using our new Posidon tool to show a clear picture
If you really want to duplicate this code in confluence then I'll do that our of courtesy.
However I'm hoping you think twice about it and save me the trouble.
Also if our developer documentation is riddled with scratch pad notes and contains
code duplicated in the repository but out of sync who's going to want to deal with
filtering that volume of information. On this track we're going to make the developer
I have been noticing that the quality of the developer documentation is dropping because
we use it as a scratch pad which is fine but we never really cleanup. Or we mix the essential
concepts in with lots of irrelevant notes. So this bypasses the purpose of transferring knowledge
quickly and efficiently to our team.
Hi Alex, and guys,
I have added some comments on the ServerEntry page :
I think it's better to add comment this way than modifying the code on
svn, if they are general comments. For code comments, or modification,
the best would be to do it directly on code, and commit the code.