We should get this over with as soon as possible (I was hoping we could do it during the break for the holidays). My understanding is it will take a couple days of svn being offline?
So let me try and respond to questions inline: > Martin's ambition #48552 involves cleaning up the svn. My ambition #80 > is to move to a next-generation versionning system so I can > branch/commit/revert on my machine locally. > Cleaning up (and moving?) svn seems like a great goal. I have really scared of moving to a new version control system. Reasoning - tools support is needed for us to get more new developers, now that we have some tool support for svn we are starting to get a lot more exciting unsupport modules created, tool support for a next-generation versioning system is likely to lag. Besides; when we moved to svn we were under the impression that this *was* our next generation versioning system? The other contender at the time (arc?) sounded really cool on a technical level. > 1. Consult and coordinate with all developers (that's YOU) > Fair enough :-) > 2. Plan an approximately four day long 'svn down' period for svn > cleanup which involves: > 1. Refractions admins making a dump of the svn > 2. Martin taking that dump and applying some magic scripts > of his; as he says in his usual non-chalant way "Well, I > already have scripts for cleaning up svn which I did for > another project and that I would like to apply to > geotools" > 3. Test loading the result in an svn locally for evaluation > 4. Bumping the refractions svn version to something recent > 5. Loading the clean dump back into the refractions svn > server. > I am still waiting to hear back about what a good target server is. The choices were OSGeo and CodeHaus. I was worried the geotools community would be stuck keeping svn up and running - but it looks like OSGeo is already got that going (and the username / password is already intergrated with their wiki etc...). > 3. Evaluating various possible improvements to the infrastructure > including looking at possibly: > A. Distributing the svn with a European copy > B. Moving the master repository over to OSGeo > C. Tracking the master repository with a bzr read-only > branch on launchpad (which cannonical offers to do for > free) > Not sure I understand this point. > D. Using bzr-svn so users who want to can use bzr while > leaving the master system as svn > 4. Evaluating a full shift over to a new versionning system > A. Look at Mercurial (Hg) since Sun is moving Java to that > B. Look at Bazaar since I am doing that anyhow > > Parts 1 and 2 are the only concrete parts of this plan, are fully > independent of the rest, and would be useful on their own so Martin is > keen to undertake this work. > Okay thanks for the clarification. > WE NEED *YOU* TO: > * Let us know of any release schedule which we should work around > so our 'svn down' period does not interfere with your work. Is > anyone releasing in the first half of January? > I would like to release a GeoTools 2.5.x before Jesse completly messes with shapefile datastore. > * Let us know of any objections you may have to this work. > No objections; I think a break out IRC on the topic would be a plus since it would be good to move on this stuff earlier rather than later. > * Look at SPIKE and wipe out any code you may have in there which > is no longer relevant. Note SPIKE will become redundant with the > next generation reversion systems so perhaps we should drop > this. > I did not make that leap of logic? But as far as I know spike was for experiments all of which should be over. We have a much better system in place with unsupported modules. > * Give us any comments, ideas, or worries you have for this > effort. > Comment: woot! faster svn checkout? Worries: evaulating next generation versioning > QUESTIONS: > * Is udig merely on the same server or actually in the same > repository as geotools? > same repository; indeed I would like to svn mv some code over to getools before the shake down. > * Is refractions able to host a clean repository using a more > recent version of svn after this work? Would it be possible to > keep the current svn untouched during the move so we could fall > back on the current situation if anything goes wrong with this > work? > I think so; the idea would be to do an svn load onto a more recent svn (using the file system rather than berkly db). > Okay, that is all for now. This email is for notification and feedback > so your comments are desired. Please keep the discussion focused though > to avoid this becoming the excuse to complain about anything and > everything. > One thing you can really do to help here is put a cap on discussion; in order to give everyone an idea about time lines. For example if Martin had time next weekend we should know that so we can have discussion sorted for a decision during Monday's meeting. Jody > P.S. On the 'next generation' front, after another marathon session (9 > hours and ~80% memory use) I finally got a branch made of the repository > in bazaar! The difficulties have been due mostly to network distance and > memory leaks (currently in the svn client not in bazaar). I'm doing this > first to learn how one of these systems works and then to evaluate using > bzr-svn to use bzr locally and the regular svn master for shared > commits. > Interesting do you have some links to bazaary or can you tell us why it is cool? Jody ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
