Re: [boost] SourceForge/CVS Progress

From: Beman Dawes (beman_at_[hidden])
Date: 2000-07-13 08:28:35

Jens Maurer wrote:

 >Beman Dawes wrote:
 >> If any one knows how to do the following on SourceForge, please let me
 >> know:
 >
 >> * Remove all the modules with names in the form
 >"failed*-test-do-not-use".
 >> * Rename the module "boostcvs" to "boost".
 >> * Remove the project CVS directories "boost" and "cvs".
 >> * Rename the directory "boostcvs" to "boost".
 >
 >I cannot comment on SourceForge, but as far as CVS is concerned, these
 >problems are outside of its scope.  In real life, I would use "rm -rf"
 >on the CVS repository as required, but SourceForge probably isolates
 >you from that.

Yes, exactly.

 >Let me add that renaming files in CVS is usually a bad idea.  If you
 >"copy, delete the original and add the copy", the revision history
 >is non-contiguous.

Yes, understood.  What happened with me, and apparently quite a few other 
new SourceForge users, was that through lack of experience (exacerbated by 
a network failure during a commit) I totally messed up the repository.  The 
obvious way to deal with it is just to delete everything and start over.

 >Regarding the policy for CVS access, here are a few ideas:
 >Goals:
 > - Make use of the additional decentralized freedom we have with CVS.
 > - Don't increase the chaos too much.
 >
 >Ideas:
 > - Everybody can read
 > - Write access is restricted to a limited set of well-known people.
 > - Authors of packages have write access to their respective packages.
 >They are encouraged to fix minor portability or implementation problems
 >without prior announcement or discussion.  Documentation improvements
 >are also encouraged.
 > - Larger changes, which do not yet warrant a formal review, should
 >be announced on the list a priori. If nobody objects, go ahead.
 > - Larger interface changes probably require a formal review, see
 >the already existing documentation.
 > - A global ChangeLog is maintained, which must contain a short
 >description of each change.  This allows the boost library maintainer
 >(Beman) to extract a change summary for the next release.
 > - Additions to config.hpp are submitted to Beman in context diff
 >format (including a documentation comment) for review regarding
 >consistent naming etc.  Beman can delegate responsibility for some
 >platforms to "platform maintainers", which may then edit the
 >respective sections autonomously: Nobody has all compilers.
 > - If in doubt, ask Beman or the list how to proceed.
 > - Before changing other people's code or documentation, send the
 >package maintainer a context diff ("cvs diff -u") of what you want to
 >do and wait for consent.

That's a good starting point.  I'll use it to seed a "CVS Policy" web 
page.  I think earlier posters identified some policies regarding 
branching, which are also important to specify, if I understand it 
correctly.  I'll try to incorporate those ideas too.

We need to experiment with backing out changes.  It may be better to let 
the people with write access just go ahead and make (presumably small) 
changes to config.hpp. These can be reverted if not acceptable, if I 
understand the process correctly. Without experience, it is hard to know 
the best policy; maybe others with experience can comment.

Minor question on diff: on some diff's it seems like -c is the correct 
switch to get a context diff, and -u doesn't produce context.  On others, 
-u is what produces context.  What's going on here?

--Beman