version control and LIP

Isaac Jones

12 Mar 2004 12 Mar '04

2:32 p.m.

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

Show replies by date

Ketil Malde

12 Mar 12 Mar

3:03 p.m.

Isaac Jones writes:

...

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?

My vote is for darcs. I haven't used if for anything sizeable yet, but it seems to work okay for my smaller stuff, so far, and from the mailing list, people generally seem happy with it. David Roundy is doing a teriffic job maintaining it, and is always responsive and helpful. People always ask for "real" applications written in Haskell, well, here's one cutting edge example. So, no tomato from me if you go the darcs route. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

Sven Panne

13 Mar 13 Mar

8:37 a.m.

Isaac Jones wrote:

...

[...] 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? [...]

I'd like to see CVS or Subversion, otherwise there will be a small tomato from my direction... :-) The reasons for this are quite simple: CVS is ubiquitous in the OpenSource world, and not only there, it is time-proven, support for it ranges from (X)Emacs modes and VisualStudion plugins to web interfaces. It has some small weaknesses, but those are well-known and most of them are solved by CVS' "younger brother" Subversion, if you really want to avoid them. We all use CVS for fptools, nhc98, etc., so I'd like to hear a *concrete problem* we have with CVS which is solved by switching to something else. VC is a rather religious topic, just like the discussion between make and ant. (I still haven't seen a really compelling argument for ant from a person who really knows GNU make, BTW.) So all I wanted to state was my personal opinion, not to start a tool war. Cheers, S.

Ian Lynagh

6:58 p.m.

(I am not a CVS expert) On Sat, Mar 13, 2004 at 02:37:52PM +0100, Sven Panne wrote:

...

It has some small weaknesses, but those are well-known and most of them are solved by CVS' "younger brother" Subversion,

Part of the problem is that, like make, the CVS issues can't easily be fixed by an evolutionary process but are small enough that there is a lot of resistance against a revolutionary change from people because of the ubiquitousness of the tools and the ersonal investment people have made in learning how they work (and how to get around their quirks!). However, this leads to a situation where we are stuck with the issues for all time. It seems to me the sensible thing for the long term is to make the jump. It has been my experience that switching from CVS to darcs was not any harder than to subversion despite the latter having a closer philosophy to CVS, so if you are going to move away from CVS then I would advocate moving straight to where you want to end up. Tools and support for the newer players is already appearing, and the faster people get interested in them and start using them the faster it will come. This is probably especially true for Haskell people and darcs. I think it would be great for the fptools repo to migrate to one of the new generation at some point in the future, and I think Simon Marlow has talked about this in the past. For the Haskell community to get experience with them on these smaller subprojects, both to be ready for when the change happens and to see which best suits our community, can only be a good thing IMO. I also think that getting Haskell used by projects in the Real World is also a Good Thing, and is worth supporting where possible. Finally, it is of course possible to synch repositories of the various systems with CVS. I'm told this is already possible for tla, and it is being worked on for darcs. Thanks Ian

seth＠haskell.org

11:45 p.m.

The reason (I believe) that you tend to get such a wide range of opinions in this area is that there is not a single common set of needs. For some situations CVS is great, for others it is simply dreadful, and those who have only experienced it in one environment or the other have very different impressions. Of course, most projects are at neither extreme, and for these projects CVS is perceived has having small weaknesses, or larger weaknesses, depending the specifics. I think the broadest line of variation is the issue of whether a centralized repository is a good thing, a bad thing, or something in between. Certainly situations where the centralization of repositories causes problems are prime candidates for paridigms other than CVS/subversion. (It is possible to decentralize repositories with add on products but if we start talking about those the discussion will expand astronomically.) If I am correct, and it is the nature of the problem space rather than the nature of the tool that is important, then Haskell should lean towards supporting a variety of tools and not requiring any particular one. Seth Kurtzberg Ian Lynagh writes:

...

(I am not a CVS expert)

On Sat, Mar 13, 2004 at 02:37:52PM +0100, Sven Panne wrote:

...
It has some small weaknesses, but those are well-known and most of them are solved by CVS' "younger brother" Subversion,

Part of the problem is that, like make, the CVS issues can't easily be fixed by an evolutionary process but are small enough that there is a lot of resistance against a revolutionary change from people because of the ubiquitousness of the tools and the ersonal investment people have made in learning how they work (and how to get around their quirks!). However, this leads to a situation where we are stuck with the issues for all time. It seems to me the sensible thing for the long term is to make the jump.

It has been my experience that switching from CVS to darcs was not any harder than to subversion despite the latter having a closer philosophy to CVS, so if you are going to move away from CVS then I would advocate moving straight to where you want to end up.

Tools and support for the newer players is already appearing, and the faster people get interested in them and start using them the faster it will come. This is probably especially true for Haskell people and darcs.

I think it would be great for the fptools repo to migrate to one of the new generation at some point in the future, and I think Simon Marlow has talked about this in the past. For the Haskell community to get experience with them on these smaller subprojects, both to be ready for when the change happens and to see which best suits our community, can only be a good thing IMO.

I also think that getting Haskell used by projects in the Real World is also a Good Thing, and is worth supporting where possible.

Finally, it is of course possible to synch repositories of the various systems with CVS. I'm told this is already possible for tla, and it is being worked on for darcs.

Thanks Ian

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Sven Panne

15 Mar 15 Mar

3:07 a.m.

seth@aedion.de wrote:

...

The reason (I believe) that you tend to get such a wide range of opinions in this area is that there is not a single common set of needs. [...]

Very true. I'm not against anything new when it really solves a problem, but I'm strictly against something simply *because* it's new. People (including me :-) have a tendency to play around with new things, which is undoubtedly good to improve one's personal knowledge, but is quite bad when it comes to a production environment. I've seen quite a few baroque VC and build systems in companies which no one could understand as whole, because so many tools were involved when plain old CVS/make plus a little bit of sh could have done the jobs easily. So what I'm proposing is: "Keep it simple." And CVS *is* simple, we all use it daily... What I'd like to hear is the set of needs we have, and if we really agree on them. For my part, I'm quite happy with the development models supported by CVS/Subversion, but there are surely other opinions. After we've reached a conclusion on our needs and goals, we should look for a technical solution, not the other way round. Cheers, S. P.S. to Seth: Interesting domain in your email address, but I really can't remember having you as an employee... :-)

Seth Kurtzberg

3:15 a.m.

Sven, I certainly agree with you about new things and using it because it is new or fancy. I am working on a contract that is using Clearcase now, and they have made something simple into something incredibly complex. This choice was dictated by the customer (which is always a bad thing); the customer then proceeded to pay for an inadequate number of licenses. I caught one of the people in my department with a clandestine CVS installation (really, I'm not making this up). I had to make him disassemble it (which I'm also not making up). The real question for something like Haskell, though, is this: is the number of cases where CVS/subversion is inadequate significant enough to devote time to supporting alternatives. I'm not convinced that the answer is yes, but I'm willing to listen to anyone who can make a case for it. Seth Sven Panne wrote:

...

seth@aedion.de wrote:

...
The reason (I believe) that you tend to get such a wide range of opinions in this area is that there is not a single common set of needs. [...]

Very true. I'm not against anything new when it really solves a problem, but I'm strictly against something simply *because* it's new. People (including me :-) have a tendency to play around with new things, which is undoubtedly good to improve one's personal knowledge, but is quite bad when it comes to a production environment. I've seen quite a few baroque VC and build systems in companies which no one could understand as whole, because so many tools were involved when plain old CVS/make plus a little bit of sh could have done the jobs easily. So what I'm proposing is: "Keep it simple." And CVS *is* simple, we all use it daily...

What I'd like to hear is the set of needs we have, and if we really agree on them. For my part, I'm quite happy with the development models supported by CVS/Subversion, but there are surely other opinions. After we've reached a conclusion on our needs and goals, we should look for a technical solution, not the other way round.

Cheers, S.

P.S. to Seth: Interesting domain in your email address, but I really can't remember having you as an employee... :-)

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

!DSPAM:4055642760317952451809!

Shae Matijs Erisson

6:30 a.m.

Seth Kurtzberg writes:

...

The real question for something like Haskell, though, is this: is the number of cases where CVS/subversion is inadequate significant enough to devote time to supporting alternatives. I'm not convinced that the answer is yes, but I'm willing to listen to anyone who can make a case for it.

Here's my case:

...

From a purely idealistic standpoint, I want to get paid to write Haskell, so if I can wave killer Haskell apps in front of my clients, it's more likely they'll let me use Haskell for what I do for them.

...

From a purely pragmatic standpoint, darcs has lowest mental and administrative overhead of any source control system I've used.

Here's the four step demo that requires a working sendmail for the push: 1. install darcs 2. darcs get http://www.ScannedInAvian.org/repos/wikiwiki 3. make a change to the scribble file in the wikiwiki directory 4. darcs push (darcs calls sendmail here) Then you can see your changes in the repository browser: http://www.scannedinavian.org/cgi-bin/darcs?wikiwiki* The wikiwiki repository is a special case, because it uses email and does not check for a valid and approved GPG signature on the emails it receives. The more general cases are to use darcs push via ssh, sudo, or email to the author. As for pushing to an email address that represents a repository, it's still simpler than CVS, since I don't have to create a new login for each person, I only need to add their public GPG key to the allowed_keys keyring. In my opinion, darcs is much simpler to start with, and to use than anything else I've seen. -- Shae Erisson - putStr $ fix("HELLO\n"++) - http://www.ScannedInAvian.org/ OSDir: Community building... interesting... what's the secret sauce? Limi: Irresponsible sleep patterns. -- Alexander Limi, one of the Plone founders http://osdir.com/Article199.phtml

Shae Matijs Erisson

7:19 a.m.

New subject: version control and LIP - I missed a step

Shae Matijs Erisson writes:

...

1. install darcs 2. darcs get http://www.ScannedInAvian.org/repos/wikiwiki 3. make a change to the scribble file in the wikiwiki directory

step 3.5 "darcs record" so it saves your changes in the local filesystem repository.

...

4. darcs push (darcs calls sendmail here)

Really, I use darcs on a daily basis, I don't know why I forgot that. -- Shae Erisson - putStr $ fix("HELLO\n"++) - http://www.ScannedInAvian.org/ OSDir: Community building... interesting... what's the secret sauce? Limi: Irresponsible sleep patterns. -- Alexander Limi, one of the Plone founders http://osdir.com/Article199.phtml

Sven Panne

12:25 p.m.

Seth Kurtzberg wrote:

...

[...] I am working on a contract that is using Clearcase now, and they have made something simple into something incredibly complex. [...]

That's exactly one of the systems I was talking about. :-P The company I'm currently working for uses a VC which is even worse and is in the top 10 of http://www.dreckstool.de/hitlist.php :-} Having used these, CVS seems like paradise... Cheers, S.

Ketil Malde

3:34 a.m.

Sven Panne writes:

...

Very true. I'm not against anything new when it really solves a problem, but I'm strictly against something simply *because* it's new.

"There are two kinds of fool: one who says this is old, and therefore good, and one who says this is new, and therefore better."

...

I've seen quite a few baroque VC and build systems in companies which no one could understand as whole, because so many tools were involved

I'm not sure this applies to the discussion, whether you use Arch, Darcs, or Subversion, they are all fairly self contained, independent of surrounding tools, and from what I've seen of them, at least as easy to understand as CVS. I'd be more worried about robustness and maturity.

...

bit of sh could have done the jobs easily. So what I'm proposing is: "Keep it simple." And CVS *is* simple, we all use it daily...

CVS may be simple for you if you use it daily. Some things are unnecessarily complicated, though: moving/renaming, branching, and merging, to mention a few. CVS is also has a bit of a threshold for contributions from "casual" users.

...

What I'd like to hear is the set of needs we have, and if we really agree on them. For my part, I'm quite happy with the development models supported by CVS/Subversion, but there are surely other opinions. After we've reached a conclusion on our needs and goals, we should look for a technical solution, not the other way round.

I've been using Subversion a bit, and am generally happy with it. It does branching neatly, but merging is a bit painful still, and requires the user to work out exactly which versions the changes he wants to merge occurred between. Move/rename is better than CVS, but tends to clutter the history a bit. And, I almost forgot, it lets you do a lot more operations locally than CVS, without needing online access to the repo. What's great about Darcs is that the threshold for new users to submit patches is very low, if I 'get' the LIP repo and fix a bug, it's very easy for me to 'push' that change (and only that one); the patch will get mailed back to the repository address, where an official maintainer can apply and test it before he integrates it into the official repo. No need to have any special commit access. And of course it's distributed, so it lets individual developers 'pull' patches from each other's repositories/working directories without involving any central repository. -kzm (I've got a loaded tomato here, and I'm not afraid to use it :-) -- If I haven't seen further, it is by standing in the footprints of giants

Seth Kurtzberg

3:39 a.m.

I did some further reading, and it does appear (to me at least) that there is a lot of overlap conceptually between darcs and arch. Not in terms of implementation, but in terms of goals. An interesting problem is thus: how to we support darcs without mucking up the works for CVS (& co.) users, and v.v. Seth Ketil Malde wrote:

...

Sven Panne writes:

...
Very true. I'm not against anything new when it really solves a problem, but I'm strictly against something simply *because* it's new.

"There are two kinds of fool: one who says this is old, and therefore good, and one who says this is new, and therefore better."

...
I've seen quite a few baroque VC and build systems in companies which no one could understand as whole, because so many tools were involved

I'm not sure this applies to the discussion, whether you use Arch, Darcs, or Subversion, they are all fairly self contained, independent of surrounding tools, and from what I've seen of them, at least as easy to understand as CVS.

I'd be more worried about robustness and maturity.

...
bit of sh could have done the jobs easily. So what I'm proposing is: "Keep it simple." And CVS *is* simple, we all use it daily...

CVS may be simple for you if you use it daily. Some things are unnecessarily complicated, though: moving/renaming, branching, and merging, to mention a few. CVS is also has a bit of a threshold for contributions from "casual" users.

...
What I'd like to hear is the set of needs we have, and if we really agree on them. For my part, I'm quite happy with the development models supported by CVS/Subversion, but there are surely other opinions. After we've reached a conclusion on our needs and goals, we should look for a technical solution, not the other way round.

I've been using Subversion a bit, and am generally happy with it. It does branching neatly, but merging is a bit painful still, and requires the user to work out exactly which versions the changes he wants to merge occurred between. Move/rename is better than CVS, but tends to clutter the history a bit. And, I almost forgot, it lets you do a lot more operations locally than CVS, without needing online access to the repo.

What's great about Darcs is that the threshold for new users to submit patches is very low, if I 'get' the LIP repo and fix a bug, it's very easy for me to 'push' that change (and only that one); the patch will get mailed back to the repository address, where an official maintainer can apply and test it before he integrates it into the official repo. No need to have any special commit access. And of course it's distributed, so it lets individual developers 'pull' patches from each other's repositories/working directories without involving any central repository.

-kzm (I've got a loaded tomato here, and I'm not afraid to use it :-)

Krasimir Angelov

14 Mar 14 Mar

4:57 a.m.

I have installed the arch under Linux and I have successfully downloaded the LIP sources from the Isaac's repository. After that I tried to install the arch under Windows/CYGWIN. The package is successfully built but when I try to checkout the LIP sources under Windows I get the following error: $ tla tag ijones@syntaxpolice.org--2003-haskell/library-infrastructure--main--0 .1 library-infrastructure--krasimir--0.1 Error calling `vu_file_is_directory_following' (File or path name too long) file ./,,changeset-for-tag.1079257604.1268.144/library-infrastructure--krasimi r--0.1--base-0.patches/new-files-archive/./{arch}/library-infrastructure/library -infrastructure--krasimir/library-infrastructure--krasimir--0.1/ka2mail@yahoo.co m--2004-haskell/patch-log PANIC: I/O error Does the arch works under Windows? All the best, Krasimir __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com

Isaac Jones

9:51 p.m.

Krasimir Angelov writes:

...

Does the arch works under Windows?

It seems that there is some support, as you've already discovered. Apparently, cygwin is only one out of 3 options: http://wiki.gnuarch.org/moin.cgi/Native_20WIN32_20Support I hope you can solve this problem. Perhaps this is another reason I should move to darcs? How's darcs support in windows? peace, isaac

Ketil Malde

15 Mar 15 Mar

2:54 a.m.

Isaac Jones writes:

...

I hope you can solve this problem. Perhaps this is another reason I should move to darcs? How's darcs support in windows?

According to the following message on the darcs-users list, there is a build for it. I don't have Windows easily available, so I don't know how well it works. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

David Roundy

6:23 a.m.

On Mon, Mar 15, 2004 at 08:54:09AM +0100, Ketil Malde wrote:

...

Isaac Jones writes:

...
I hope you can solve this problem. Perhaps this is another reason I should move to darcs? How's darcs support in windows?

According to the following message on the darcs-users list, there is a build for it. I don't have Windows easily available, so I don't know how well it works.

I asked Vlad recently (off-list) about the state of the windows darcs build, since I don't have windows myself. There are apparently a few issues remaining. First off, email is a problem if you want to send patches via email. There is MAPI code, but apparently it doesn't work and noone knows how to fix it. There's also a bug that shows up in file handling, which is going to be a bit trickier to track down, especially since Vlad doesn't know haskell... but I've also heard from satisfied windows users, so this may be a rare bug or one that people can work around (and haven't bothered reporting). There isn't that much code in darcs that is platform-dependent. Most of the "hard" windows problems other than MAPI support (e.g. threading, which is done using either native windows calls or the pthreads library, I'm told both now work) have already been dealt with. So what remains is little things like the buggy renameFile on windows (which fails if the new filename already exists--this is just an example of something I've already had to deal with), which are harder to track down, but are at least "pure haskell" problems. -- David Roundy http://www.abridgegame.org/darcs

Krasimir Angelov

3:27 a.m.

--- Isaac Jones wrote:

...

Krasimir Angelov writes:

...
Does the arch works under Windows?

It seems that there is some support, as you've already discovered. Apparently, cygwin is only one out of 3 options:

http://wiki.gnuarch.org/moin.cgi/Native_20WIN32_20Support

...

I hope you can solve this problem. Perhaps this is another reason I should move to darcs? How's darcs support in windows?

I will try to install the native arch package but if we need to choice between arch and darcs I will prefer darcs. I both case I need to learn a new tool which is a disadvantage for me. I prefer the darcs because it is written in Haskell and because I found the theory of patches very original. Of course these arguments are very subjective and the real arguments will be stability, portability and supported features. Cheers, Krasimir __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com

Seth Kurtzberg

3:32 a.m.

I didn't mean to imply anything negative about darcs. I couldn't do that because I haven't had a chance to become familiar with it. My bias is also to learn darcs first because it is written in Haskell. I think that is a legitimate argumentl However, it hasn't been established that it has to be darcs or arch. I understand what Krasimir is saying (that everyone has a limited amount of time) but that really is irrelevant to the technical discussion. Seth Krasimir Angelov wrote:

...

--- Isaac Jones wrote:

...
Krasimir Angelov writes:

...
Does the arch works under Windows?

It seems that there is some support, as you've already discovered. Apparently, cygwin is only one out of 3 options:

http://wiki.gnuarch.org/moin.cgi/Native_20WIN32_20Support

...
I hope you can solve this problem. Perhaps this is another reason I should move to darcs? How's darcs support in windows?

I will try to install the native arch package but if we need to choice between arch and darcs I will prefer darcs. I both case I need to learn a new tool which is a disadvantage for me. I prefer the darcs because it is written in Haskell and because I found the theory of patches very original. Of course these arguments are very subjective and the real arguments will be stability, portability and supported features.

Cheers, Krasimir

__________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

!DSPAM:4055694a91924469820903!

Krasimir Angelov

3:43 a.m.

--- Krasimir Angelov wrote:

...

--- Isaac Jones wrote:

...
Krasimir Angelov writes:

...
Does the arch works under Windows?

It seems that there is some support, as you've already discovered. Apparently, cygwin is only one out of 3 options:

http://wiki.gnuarch.org/moin.cgi/Native_20WIN32_20Support

...

...
I hope you can solve this problem. Perhaps this

is

...
another reason I should move to darcs? How's darcs support in windows?

I will try to install the native arch package but if we need to choice between arch and darcs I will prefer darcs. I both case I need to learn a new tool which is a disadvantage for me. I prefer the darcs because it is written in Haskell and because I found the theory of patches very original. Of course these arguments are very subjective and the real arguments will be stability, portability and supported features.

Cheers, Krasimir

P.S. My real preference is CVS just because I already use it and found it good enough. __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com

Graham Klyne

5:39 a.m.

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 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 #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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

seth＠cql.com

4:44 p.m.

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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

!DSPAM:40558c49250291867175997!

Seth Kurtzberg MIS Corp. 480-661-1849 seth@cql.com CQL - the choice for embedded databases

Alastair Reid

6:50 a.m.

...

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.

Lot's of interesting discussion triggered by this. darcs sounds intriguing but there's a lot of (reasonable) resistance to change. It seems to me that the best way to proceed is to try darcs on a project which is relatively new (low cost of switching to it), small (low cost of switching away from it if experiment fails), and important (so major players will try it out). So, if you're still willing to try darcs for LIP, I think that would be a fine choice. The worst that can happen is that you change to CVS or some such in a few months. -- Alastair Reid www.haskell-consulting.com ps The above is written without actually having tried darcs and having a pretty large investment in using CVS.

7736

Age (days ago)

7739

Last active (days ago)

List overview

Download

21 comments

12 participants

participants (12)

Alastair Reid
David Roundy
Graham Klyne
Ian Lynagh
Isaac Jones
Ketil Malde
Krasimir Angelov
Seth Kurtzberg
seth＠cql.com
seth＠haskell.org
Shae Matijs Erisson
Sven Panne

version control and LIP

tags

participants (12)