Hi Erik, I think that moving to a distributed SCM system is a bit much and if any other system is to be used, I'd say Subversion would do well enough for better tracking of changes. The sync job I think would also be somewhat of a headache. Beyond that though, I like that Sourceforge supports Subversion and that using Subversion is going to be an easy jump from CVS than the others. SVN has lots of GUI tools that work on most platforms so that is a plus for those who like to see diffs and histories that way. I'd also mention that there are users interested in compiling from CVS who I think would be alright with using SVN but might be a jump with other tools (maybe not though). Also with distributed SCM, if developers are all working on their own changes in their branches, I have a feeling that it'll be much easier for things to fracture if someone decides they don't like someones changes in another branch and decide not to merge there. Perhaps a bit of paranoia and inexperience with distributed SCM on my part though. As for OS9, I think Anthony is taking a break from working on Csound now and unsubscribed from the mailing lists after the latest rumblings on the dev list, so might not be an issue (but would be for anyone else wanting to do OS9 work). I do think that communication is an issue, but that it is also a common issue amongst open source projects. Setting up policies seems like a good idea (could be added to the CVS as a developer README) as long as they are flexible and that we all recognize we're all human and might step on toes once in a while and that it's not personal. steven On 5/19/06, Erik de Castro Lopo wrote: > Hi all, > > I am trying to bring a reasoned approach to solve the issues that > recently caused one of our developers to come close to quitting > work on Csound. > > These issues are (as I understand them): > > i1) People changing or reformatting code while others are currently > working on it. > i2) People moving code within the tree while others are currently > working on that code. > i3) People disagreeing about what should or should not go > into Csound. > i4) People deleting code before getting agreement from the other > developers that said code should be deleted. > > If there are other issues that I didn't list here, now is the time > to bring them up, either here on the list or in private email to me. > > Issues i3 and i4 are problems with communication. The only thing that > I can really suggest here is that people use the mailing list to > communicate. Policy might help as well. One policy that we probably > should have is that no code or functionality gets deleted without > some sort of a pre-defined approval process. This may also be > appropriate for new functionality. > > Issues i1) and i2) above are largely due to the use of CVS. Other more > modern revision control systems track and deal with changes of these > kinds so much better than CVS. The problem with some of these other > RC systems is that the really good ones (SVN is good, but not really > good) don't play nice with windows (and as Anthony Kozar points out > Mac OS9). > > I have used CVS, SVN, GUN Arch, Bzr, Perforce, Visual Source(un)safe > Aegis and probably some that I have forgotten. RC systems like GNU Arch, > Bzr and Mercurial (and probablay others) are designed for the kind of > distributed development that Csound uses. These systems have far better > branching than CVS or SVN provides and more importantly better automatic > (within reason) merging between branches and tracking of those merges > than either CVS or SVN. > > Ignoring the issues of windows and OS9 interaction, GNU Arch and Bzr > (both of which I am currently using) would solve most of the problems > related to issues i1 and i2. > > To me, this suggests that some of the more adventurous developers may > want to move to one of these more advanced RC systems to make > interaction easier and less painful. In order not to freeze out the > OS9 and windows developers, this new RC system would have to work > pretty much in parallel with the existing CVS which gives us a new > problem; how to sync between CVS and the new parallel RC system. For > most of the more advanced systems, the CVS to new RC system would be > relatively painless leaving only the issue of moving changes from the > new system back to CVS. > > At the moment, the only solution I can think that will allow changes > to move from the new system to CVS is if the CVS users agreed to a > pre-set weekly/fortnightly/whatever 12 hour period when they should > not have any pending changes. This would allow file renames and moves > to happen with a reasonable guarantee that none of the CVS users > toes would get stepped on. Once the changes have been migrated to CVS, > a "cvs update" in each user's CVS work area should bring them up to > date. > > So, my questions: > > - Are people interested in working to resolve these issues? > - Would the parallel use of CVS and SomeOtherRC tool help? > - Are the more adventurous developers willing to do the hard > work of using SomeOtherRC and the exta work of syncing > changes back to CVS? > > Comments please. > > Cheers, > Erik > -- > +-----------------------------------------------------------+ > Erik de Castro Lopo > +-----------------------------------------------------------+ > "Every time you get a windows programmer asking you to write some > ass-backward workaround, think of it as a crack junkie asking you > to help stuff his pipe because his hands are too shaky." > -- Conrad Parker > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel > ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642 _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net