Forum OpenACS Improvement Proposals (TIPs): Re: TIP #25 (Proposed): No direct manipulation of the CVS repository

What do you mean by "manipulating an arch repository"? The repository should not be directly manipulated as we often are forced to do with CVS. It can be manipulated in many ways with the "tla" command, just like the "cvs" command.

Regarding (2): How many of our _developers_ committing code to the OpenACS tree rely exclusively on Windows, without access to a *nix box of some kind? My experience with the community says that it's a very very limited number. Do we even have anyone running OpenACS on Windows?

Sure it would be great if it worked everywhere, but we have to consider if it's worth it to continue to inflict pain on the entire development community because of a very restricted set of developers that we're not even sure exists.

Of course we'd continue to provide things like nightly tar balls, bug-tracker where people can submit patches, etc. Using arch would definitely _not_ isolate users who rely exclusively on Windows.

Re: 3) Very much agreed, and I'm working on it. As far as "best practices" for CVS, what I usually see is a hodge-podge of hacks to work around its defficiencies. But if you're working on a system that doesn't have those defficiencies, many of the "best practices" are not necessary anymore.


What do you mean by "manipulating an arch repository"?

For example, for CVS I can interact with a CVS repo with any of the following tools:

  • WinCVS (CVS Gui for windows)
  • TortoiseCVS (Windows Explorer shell extension)
  • pcl-cvs in Emacs
  • CVS plugin for Eclipse
  • ViewCVS web interface

Just to name a few. That way my less command-line savvy users have the warm fuzzies of a GUI. And WinCVS in particular has a really cool graphical branch viewer that makes it easy to see what happened in the past. Those kinds of things. "Third Party Tool Support" for lack of a better term is what I was thinking.

Emacs integration in particular is something we would really miss.