version control and LIP
seth at cql.com
seth at cql.com
Mon Mar 15 14:44:24 EST 2004
Graham Klyne writes:
> The computing world is sooo full of new tools and techniques to be
> mastered; each new tool, even if quite modest in its demands on a user,
> can become a drag on getting a project off the ground. (I recall an
> argument from the old look-and-feel copyright wars: the users have *much*
> more investment in a particular user interface than the software
> developers.)
>
> So, speaking for myself: I use CVS locally, and I'm slowly getting the
> hang of using it remotely, via SSH. I also like the fact that it has a
> GUI front-end on Windows systems in the form of WinCVS. I'm not
There is a GUI tool for CVS in Linux (more than one, most likely). The ECOS
project (which is on redhat.com) has a tcl/tk GUI cvs controller. There are
also web access thingies that can be used with operating systems that don't
have direct support for CVS.
This doesn't really speak to the issue of which version control system to
use, I'm just pointing it out.
> enthusiastic about learning any other version control system, unless the
> added benefits are truly compelling.
>
> Reading ahead this thread, I feel I should try and indicate what I think
> would be improvements:
> - more obvious functionality, especially for simple operations like adding
> new projects/directories/files and retrieving them to new workspaces, and
> fetching updates to existing workspace (CVS seems a little quirky in this
> area).
> - secure remote operations "out of the box" (or "out of the installation
> kit"). (I have found that getting WinCVS to work with SSH has been a
> somewhat muddled process.)
> - widespread tool availability, including repository hosting on Linux and
> Windows platforms, preferably with a simple and obvious GUI-style
> front-end (also multi-platform).
> - repository compatibility/cross-accessibility (what do I do with all my
> old CVS repository data?)
>
> It's difficult for me to see any of these as truly compelling for change.
> Maybe: "easier to use, especially for common functions and secure remote
> operations" might just win the day for me.
>
> I've never really had to deal with large-scale multi-user projects, so
> there are probably possible improvements in that area that don't appear on
> my radar
There are, and they are extremely difficult to manage in CVS. However, as
several people have commented, it is not yet proven that the alternatives
are better.
>
> #g
> --
>
> At 14:32 12/03/04 -0500, Isaac Jones wrote:
>> Greetings.
>>
>> I've been using the arch (tla) version control system for the Library
>> Infrastructure Project. Since its designed to be distributed, arch
>> has many advantages over a system like CVS. You can read about them
>> here:
>>
>> http://web.verbum.org/blog/freesoftware/distributed-future
>>
>> So I'm thinking about how to proceed with the VC of LIP. Someone
>> asked me to move it to the central CVS repository, and someone else
>> asked if I would move it to darcs.
>>
>> I'm using arch at work, and since I'm interested in such system, I'm
>> using darcs at home for my Debian packages (darcs is in Debian
>> unstable now, by the way). Darcs is written in Haskell.
>>
>> I know I've harassed several of you to read about arch, so my question
>> is, will anyone throw tomatoes at me if I switch to CVS or darcs? Is
>> anyone else using my arch repository?
>>
>> By the way, the Library Infrastructure Project is still moving
>> forward; I've been sending patches for stuff we'll need to the
>> upstream author of HMake (CC'd).
>>
>> peace,
>>
>> isaac
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>
> ------------
> Graham Klyne
> For email:
> http://www.ninebynine.org/#Contact
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
> !DSPAM:40558c49250291867175997!
>
>
Seth Kurtzberg
MIS Corp.
480-661-1849
seth at cql.com
CQL - the choice for embedded databases
More information about the Libraries
mailing list