I was thinking a revision history inside the file. A simple line item entry. It could be the same message used during a svn commit.
E.g #REVISION HISTORY # 2007-5-20 Fixed <some> issue with <some> function. # 2007-4-40 created <something> On May 21, 2007, at 1:27 AM, Philip Neustrom wrote: Revision log, you mean something like the svn change log? I think we oughtta keep that in svn and in a single ChangeLog file in the module. --philip On 5/20/07, Adam Dewitz <[EMAIL PROTECTED]> wrote: > We should also decide on a format for file/module header comments. I > would like to suggest: > > """ > FileName.py : a description of what the code in this file does > > This software is licensed as described in the file COPYING, which > you should have received as part of this distribution. The terms > are also available at http://projectsycamore.org/license. > If newer versions of this license are posted there, you may use a > newer version instead, at your option. > > This software consists of voluntary contributions made by many > individuals. For exact contribution history, see http:// > www.projectsycamore.org/Contributors > > """ > > This is borrowed from the Subversion who have done a great job of > building a development support system (We should probably borrow a > few more things from them). > > > Would it be wise to keep a revision log in the individual files as > well? > > > AD > > > > > On May 20, 2007, at 9:22 PM, [EMAIL PROTECTED] wrote: > > I've started a doc about coding conventions[1] used in Sycamore. I've > noticed a lot of annoying inconsistencies and I'd like to start fixing > things. Once we all decide on the best practices I'll clean up the > code. > Please look at the doc and let me know what you think. This will > involve > database changes so it will require an SQL patch that I'll produce. I > don't have that much experience with postgres so I might need some > help on > that side. > > I've produced a simple Entity Relationship Diagram for Sycamore[2] to > view > import the contents at this website[3]. I didn't add the views yet. > Also, > there are no relations in my diagram because that's exactly how things > exist after buildDB.py is run. Adding foreign keys with cascading > updates,deletes *may* reduce some complexity in the code (but I > haven't > looked). The DB does also need some normalization. I imagine we can > eliminated a few tables to do exactly the same functions. > > Scott > --------- > [1] http://www.projectsycamore.org/Coding_Standards > [2] > http://sycamore.devjavu.com/projects/sycamore/browser/branches/ > sapling/doc/ERD.xml > [3] http://ondras.praha12.net/sql/demo > > _______________________________________________ > Sycamore-Dev mailing list > [EMAIL PROTECTED] > http://www.projectsycamore.org/ > https://tools.cernio.com/mailman/listinfo/sycamore-dev > > _______________________________________________ > Sycamore-Dev mailing list > [EMAIL PROTECTED] > http://www.projectsycamore.org/ > https://tools.cernio.com/mailman/listinfo/sycamore-dev > _______________________________________________ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev _______________________________________________ Sycamore-Dev mailing list [EMAIL PROTECTED] http://www.projectsycamore.org/ https://tools.cernio.com/mailman/listinfo/sycamore-dev