[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kuml
Subject:    Re: [Slightly OT] Q about configuration and revision management
From:       Richard Moore <rich () ipso-facto ! freeserve ! co ! uk>
Date:       2000-02-10 19:32:16
[Download RAW message or body]



Stefan Mars wrote:

> Would you be interested in a replacement for CVS, with added and expanded
> capabilities ( relative against CVS )? If so, what features would you like
> the most?

There are definitely some things about CVS that could be improved, but
I am not sure a wholesale replacement is called for. That said, however
If you want to have a go then don't let anyone stand in your way. For it
to be useful in a larger sense though you will need to ensure you can
import and export CVS/RCS compatible data.

Things I would want that CVS does not have:

- Ability to revert and diff your changes without connecting to the
network server. Simply a matter of keeping a pristine copy on the
client this can also speed up network access significantly (though
it will double the size of the checkout).

- Better management of branches and tags
  - Ability to apply fixes to more than one branch at once
  - Any easy way to query the available branches and tags

- A more complete concept of a source module. CVS is lacking in this
regard because it confuses the concepts of a directory and a module
a bit too much. For example it is difficult to ensure that the modules
file is kept up to date, this means that remote users may not be able
to find out about all modules.

- A souped up $Id$ that can be used to identify a build and depends
on all the files in the module.

- The ability to delete directories via the network.

- Designed to support mirroring. e.g.. I would like to run a local cvs
server which caches cvs.kde.org to allow me to extract log files etc.
without needing to dial in. Even better would be real support for
distribution with either a tree or a network of servers.

- Builds as a shared library to allow applications such as GUI front
ends to use the code without needing sub processes. This also needs
to support progress information etc. This would allow a command line
client, a gui client and a server to share the same code.

- Designed for automation via scripts (specifically in the server) so
that people can extend the facilities.

- Integration with a bug tracking system so that when you commit a fix
you update the bug list too. This could use the scripting facilities
mentioned above.

- Efficient use of memory even for large checkouts.

- The ability to support nested modules (so modules can have submodules).

- Something like cvsup that isn't written in modula 3.

Rich.

> 
> Feel free to answer me, send questions to me, or maybe just put me against
> the wall and flame me :-)
> 
> /Stefan Mars
> mars@lysator.liu.se

-- 
     Richard Moore		rich@ipso-facto.freeserve.co.uk
http://www.robocast.com/	richard@robocast.com
http://developer.kde.org/	rich@kde.org

[prev in list] [next in list] [prev in thread] [next in thread]