On Wednesday 20 June 2007 08:33, Joel B. Mohler wrote: > Here's some options for the purposes of voting on what should happen for > the sage_c_lib.spkg: > 1) Have a mercurial repository in the root of the spkg for the spkg > scripts and a *seperate* mercurial repository for development of the actual > code in the src/ subdirectory (but this separate repository would be kept > in the spkg as well). > 2) Have a single mercurial repository for both the spkg-* scripts and the > actual code in the src/ subdirectory. > 3) Keep the actual code source control outside the spkg and release > non-version controlled tarballs from this to be packaged in the spkg. > > I vote for #2. That seems sad to not make a distinction between 'upstream' > and spkg-scripts, but the stuff in sage_c_lib currently seems quite unique > to sage so there is little value to separate them.
Oops, I should clarify some things. Taking option #2 will result in a loss of the change-log for the code in sage_c_lib unless someone knows how to tell hg to move all the files down one layer in the directory hierarchy (or, in other words, move the .hg repository up one layer.) There isn't much change-log so I don't regard this as a big problem, but perhaps opinions differ. Look at the output of 'hg status' in the root directory of the unzipped http://sage.math.washington.edu/home/dfdeshom/custom/spkg/sage_c_lib-2.6.p1.spkg to see more details about what I mean (This is Didier's refactoring of the sage_c_lib spkg). The hg repository in the root of this spkg was not updated to see that all the source files were moved down one layer. -- Joel --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
