Projects / COllaborative DEvelopment S...

COllaborative DEvelopment SHell

CODESH (COllaborative DEvelopment SHell) is an automatic persistent logbook for sessions of personal command line work. It records what and how is being done, for private use/reuse and for sharing selected parts with collaborators. It is an intelligent shell that automatically logs user's shell sessions. Sessions are uniquely tagged and stored in local or distributed backend repositories (ASCII flat file or Subversion or CVS based) and can be extracted and reproduced at any time by the user who created the session or by collaborators located anywhere in the world.

Tags
Licenses
Implementation

RSS Recent releases

  •  24 Jul 2013 23:06

    Release Notes: This release deprecates code like os.popen and string exceptions (brought to Python 2.6 standards). Corresponding warnings disappear.

    •  11 Mar 2010 22:05

      Release Notes: This is the starting point for a new development cycle. The Web server hosting codesh has migrated to new hardware.

      •  11 Jul 2008 07:05

      Release Notes: The test suite was streamlined to produce shorter and more focused output, making it easier to scan the results from each test. The code for the various backends was cleaned up. A problem when extracting flex sessions (the log-modify-and-replay mechanism of CODESH) from remote CVS backends was fixed.

      •  02 Jul 2008 17:54

      Release Notes: The focus of this version is the distributed computing (remote) aspects of CODESH. A new subdirectory "remote" is introduced. It contains sample scripts showing how to set up remote (client/server based) Subversion, CVS, and ASCII backends, along with detailed documentation. The scripts can be used not only to set up CODESH backends, but general purpose remote Subversion or CVS pserver repositories as well. As usual, extreme caution and studying the documentation in advance is recommended before setting up servers.

      •  22 Jun 2008 19:17

      Release Notes: This version improves the user experience by hardening the frontend and the Subversion, CVS, and ASCII backends. The checks on user input are extended, and now users are warned in basically all situations if they try to run commands with wrong number of parameters. The verifications if the backend repositories are up and running when the users try to access them are extended with dynamic checks, approaching complete coverage.

      RSS Recent comments

      17 Nov 2006 14:32 bourilkov

      Re: Unfortunate CVS Dependency

      > Many engineers have nothing to do with,

      > and in fact avoid, CVS. You have a very

      > nice tool here. Why do I need CVS to

      > use it? Why can't it simply dump its

      > logs in a directory and only use CVS if

      > I explicitly ask it to. And if it uses

      > CVS, shouldn't it also use Subversion

      > and any other popular versioning system.

      > Best would be if all that were optional

      > and anyone could use the basic

      > functionality that only your tool

      > provides.

      Dear Richard,

      Thank you for your comment, you bring up a very important point. In the course of developing the CODESH architecture we have separated the persistency backend (codeshb.py) from the user interface so they are basically independent. I will add that we are currently working on a subversion backend and users will be able to choose by changing a configuration parameter at strartup. As you say, one could have an option to just dump ascii files which are easy to port and introduce no dependencies. I'll take this as a feature request for our to-do list, thanks for the suggestion.

      I will add that our architecture hides cvs (or future backends) from the user, so you don't need to know much about cvs - with its not very simple syntax - to start using it.

      Best, Dimitri Bourilkov

      17 Nov 2006 07:22 r_e_h

      Unfortunate CVS Dependency
      Many engineers have nothing to do with, and in fact avoid, CVS. You have a very nice tool here. Why do I need CVS to use it? Why can't it simply dump its logs in a directory and only use CVS if I explicitly ask it to. And if it uses CVS, shouldn't it also use Subversion and any other popular versioning system. Best would be if all that were optional and anyone could use the basic functionality that only your tool provides.

      Screenshot

      Project Spotlight

      juntaDados

      A GNU/Linux multimedia distribution that is targeted at audio, video, and graphics producers.

      Screenshot

      Project Spotlight

      Quenlig

      An online interactive tutorial and free text assesments.