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

Steven Yi wrote:

> 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.

I use SVN at work so I know it well. I also use GNU Arch and Bzr at
home and know them even better.

The thing that the distributed RC systems bring us is sane handling
of branches. For instance with GNU Arch, I often create a new branch
to work on a specific feature. Working on lots of different branches
like this means that its *much* less likely for developers to step
on each others toes.

The other thing that distributed RC systems brings us less reliance 
on a central server which can go down and prevent everyone from 
grabbing the source and/or commiting. With distributed RC systems,
everyone can have their own branch on their own machine and only 
merge to the public branch when they are happy with the code.

Aside from the fact that subversion requires a centralised server,
its main problem is lack of sane handling of merges across branches.
William Nagle , author of "Subversion Version Control" says it best:

    "One of Subversions biggest weaknesses is its lack of adequate 
    internal tracking for merges."

The distributed RC systems keep track of all the things that have been
merged into a branch and avoid attempting to merge the same changeset
twice. SVN is not that smart.

> 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.

I don't see how that is any more likely with distributed RCS than with
CVS.

>  Perhaps a
> bit of paranoia and inexperience with distributed SCM on my part
> though.

Distributed revision control systems are like sex. Until you've
tried them you don't know how good they can be.

Moving from CVS to distributed RC will bring great benefits. Moving
from CVS to SVN will only bring a few. One of the downsides of
SVN is that Anthony Kozar cannot access SVN from Mac OS9.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo
+-----------------------------------------------------------+
"Well behaved women rarely make history." -- Dorothy 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