RE: [Haskell-cafe] fptools in darcs now available
On 28 April 2005 04:52, John Goerzen wrote:
I am pleased to announce that I have used tailor.py to successfully convert the entire history of fptools HEAD branch, dating back to 1996, from CVS to darcs. For those of you that don't know, fptools represents the development area for the GHC Haskell compiler as well as many other related projects. It contains 21,949 changesets.
Great news, thanks John. Is it possible to set up a two-way synch so we can move over to darcs gradually? It's not really practical for us to move over in one go, we've simply accumulated too many dependencies on CVS, and there are lots of people using the repo with CVS. If we had a two-way synch, we can experiment with darcs non-destructively. Off the top of my head, a few other things we need before we can even think of switching over: - split up the full fptools repo into pieces (as we discussed on #haskell). - a web interface to the repo - commit mails to the cvs-<blah>@haskell.org lists Cheers, Simon
Simon Marlow (simonmar@microsoft.com) wrote:
Great news, thanks John.
Is it possible to set up a two-way synch so we can move over to darcs gradually? It's not really practical for us to move over in one go, we've simply accumulated too many dependencies on CVS, and there are lots of people using the repo with CVS. If we had a two-way synch, we can experiment with darcs non-destructively.
Great news, thanks Simon. Nice to hear you are considering to move to darcs. Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD
Gour wrote:
Simon Marlow (simonmar@microsoft.com) wrote:
Great news, thanks John.
Is it possible to set up a two-way synch so we can move over to darcs gradually? It's not really practical for us to move over in one go, we've simply accumulated too many dependencies on CVS, and there are lots of people using the repo with CVS. If we had a two-way synch, we can experiment with darcs non-destructively.
Great news, thanks Simon.
Nice to hear you are considering to move to darcs.
Hmmm, I don't want to spoil all the enthusiasm for a new tool, especially a Haskell-based one, but being an old CVS veteran who recently fell into love with subversion, I'd really like to know the benefits switching to darcs. I hoped that one day the fptools will move over to subversion, just like other projects (e.g. gcc, see http://gcc.gnu.org/wiki/SvnPlan). Basically I'm very happy with the working model of CVS, and subversion improves the rough edges like non-atomicity, lack of renaming, complicated administration, etc. The learning curve for CVS-aware people is extremely low with subversion, it is very actively maintained, has tons of front ends, editor modes, and is used by large Open Source sites like http://www.berlios.de/ and large projects. So my question in a nutshell: Why shall we move away from the mainstream when the rest of the world (or most of) is quite happy with CVS or is moving to subversion? I'm not completely against it, but we should have very, very good reasons to do so. Cheers, S. P.S.: Yes, I'm aware of other development models like the one used for the Linux kernel, where CVS/subversion are not appropriate, but is fptools really a similar project? I don't expect hundreds of people working in a very distributed manner on extensions of e.g. a type checker... :-]
On 20050501T202815+0200, Sven Panne wrote:
So my question in a nutshell: Why shall we move away from the mainstream when the rest of the world (or most of) is quite happy with CVS or is moving to subversion?
Do you have evidence for your presupposition? My read of the situation is that CVS is old and rusty, and while many people have not noticed it, many have; those that have noticed it, are looking for a replacement - and there are several contenders, subversion being the oldest but not by any means dominant. -- Antti-Juhani Kaijanaho http://antti-juhani.kaijanaho.info/ Blogi - http://kaijanaho.info/antti-juhani/blog/ Toys - http://www.cc.jyu.fi/yhd/toys/
[ Slowly redirecting to the cvs-fptools list... ] Antti-Juhani Kaijanaho wrote:
On 20050501T202815+0200, Sven Panne wrote:
So my question in a nutshell: Why shall we move away from the mainstream when the rest of the world (or most of) is quite happy with CVS or is moving to subversion?
Do you have evidence for your presupposition?
Yes, I have tons of empirical evidence: There are many projects which are much larger than fptools (like KDE or GNOME, all the GNU stuff on Savannah) which exclusively use CVS, others use CVS but move to Subversion in the near future (like gcc), there is a comparison of Open Source hosting sites at http://www.ibiblio.org/fosphost/exhost.htm (only CVS and Subversion are used) etc. So either all those thousands of people in these projects are silly and/or ignorant or fptools is so much different...
My read of the situation is that CVS is old and rusty, and while many people have not noticed it, many have; those that have noticed it, are looking for a replacement - and there are several contenders, subversion being the oldest but not by any means dominant.
Don't get me wrong: I am quite aware of the limitations of CVS and I would *never* start a fresh project with CVS. But Subversion is a very worthy successor and being "the oldest" as you mentioned is a definite plus in the mission-critical area of version management systems. I don't want to start a version management jihad, I just want to understand and discuss the reasons for the plan mentioned by SimonM to move fptools to darcs. For our concrete project: In which respects (i.e. use cases) is darcs better than Subversion? There is no silver bullet for version management, everything depends on the intended use cases and the development model, see e.g. http://subversion.tigris.org/subversion-linus.html. Cheers, S.
On Mon, 02 May 2005 00:20:40 +0200
Sven Panne
Don't get me wrong: I am quite aware of the limitations of CVS and I would *never* start a fresh project with CVS.
OK, so you agree that CVS has limitations.
But Subversion is a very worthy successor and being "the oldest" as you mentioned is a definite plus in the mission-critical area of version management systems.
Subversion only fixes the most obvious deficiencies of CVS, the lack of atomic commits and the inability to preserve history across rename events. However, there are other things that you would want to do in a revision control system. The main one is to set up branches and merge from branch to branch with as little human intervention as possible. SVN does not improve on CVS's rather poor across branch merging capabitilites where as others like Darcs and GNU Arch do. I haven't use Darcs, but I have been using GUN Arch for over 12 months and use branches for experimental work, sometimes as many as 10 branches on a single projects. Arch allows me to merge from branch to branch pretty mucu at will. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam@mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ "Java, the best argument for Smalltalk since C++." -- Frank Winkler
On Sun, May 01, 2005 at 08:28:15PM +0200, Sven Panne wrote:
Gour wrote:
Nice to hear you are considering to move to darcs.
Basically I'm very happy with the working model of CVS, and subversion
darcs would allow you to locally record intermediate stages of a change, making it easier to revert to the last good state if you screw up or decide something would be better done a different way. You can also unrecord one of the previous intermediate local commits you have made to fix a bug or do it in a better way. Then, when you have finished the changes and are happy with it all, you can either send of the set of smaller changes (which might make the history more understandable) or unrecord them all and rerecord the whole thing (so it looks to the outside world like you just did it all at once, as is the current case). You can also more easily send only some of the changes you have made to the main repo if you also have some unfinished stuff you are working on. You can also do all this while on a plane, without bandwidth at a conference, or whatever. Thanks Ian
On 02/05/2005, at 4:28 AM, Sven Panne wrote:
So my question in a nutshell: Why shall we move away from the mainstream when the rest of the world (or most of) is quite happy with CVS or is moving to subversion? I'm not completely against it, but we should have very, very good reasons to do so.
Darcs will have one major advantage over Subversion for a particular project in fptools: GHC. There are plenty of folks who I think would like to branch GHC for their own experimental use (I already know of one such person in my own research group), which where Darcs's distributed model really helps. While Subversion is much, much better than CVS -- I use it everyday at work -- I think users being able to make their own branches of GHC is a compelling case for using Darcs. -- % Andre Pang : trust.in.love.to.save http://www.algorithm.com.au/
Sven Panne (Sven.Panne@aedion.de) wrote:
So my question in a nutshell: Why shall we move away from the mainstream when the rest of the world (or most of) is quite happy with CVS or is moving to subversion? I'm not completely against it, but we should have very, very good reasons to do so.
Amongst other reasons mentioned by others, I prefer darcs 'cause it does not have database dependence and I heard enough stories of corrupted databases & subversion. (the same argument applies to Monotone as well.) Sincerely, Gour
Cheers, S.
P.S.: Yes, I'm aware of other development models like the one used for the Linux kernel, where CVS/subversion are not appropriate, but is fptools really a similar project? I don't expect hundreds of people working in a very distributed manner on extensions of e.g. a type checker... :-]
_______________________________________________ darcs-users mailing list darcs-users@darcs.net http://www.abridgegame.org/mailman/listinfo/darcs-users
-- Registered Linux User | #278493 GPG Public Key | 8C44EDCD
Sven Panne
The learning curve for CVS-aware people is extremely low with subversion,
In my experience, darcs has the lowest scm learning curve, especially for users who haven't used an scm before.
So my question in a nutshell: Why shall we move away from the mainstream when the rest of the world (or most of) is quite happy with CVS or is moving to subversion? I'm not completely against it, but we should have very, very good reasons to do so.
P.S.: Yes, I'm aware of other development models like the one used for the Linux kernel, where CVS/subversion are not appropriate, but is fptools really a similar project? I don't expect hundreds of people working in a very distributed manner on extensions of e.g. a type checker... :-]
There are many projects (including fptools) to which I would have contributed patches if the startup cost of sending a patch weren't so high. With darcs, every checkout is an independent repository, and if you have a working sendmail/MAPI setup you can send any changes you make back to the source of your checkout with a single command. With darcs I immediately get the benefits of source control without needing to make a separate copy of the master repo. With svn or cvs, I can't locally get all the benefits of the system without a user account for the repository. With cvs/svn I can't hack around in an anonymous checkout and only commit my patches back to the original repo once I've decided I want to join the project. darcs doesn't require a unix account for committers, it can receive and authenticate patches via gpg-signed emails. Why should authentication information be tightly bound to a repository? Non-core members can share patches. If darcs sends to a public list anyone who absolutely needs a patch can apply it before it gets to the main tree. That patch will still work even if the patch never gets to the main tree. There are a large number of potential committers on the #haskell irc channel alone. Lots of people end up wishing for small changes to the code in fptools but usually end up forking a library or module for their product instead. lambdabot, the Haskell irc bot is a good example of the low cost of patch submission encouraging rapid development. There's a surprising number of people who've committed small but useful features because it's so easy to do. (Much of this content is paraphrased from a recent conversation on #haskell. Several people contributed salient points.) -- Programming is the Magic Executable Fridge Poetry, | www.ScannedInAvian.com It is machines made of thought, fueled by ideas. | -- Shae Matijs Erisson
On Thu, Apr 28, 2005 at 10:01:05AM +0100, Simon Marlow wrote:
On 28 April 2005 04:52, John Goerzen wrote:
Is it possible to set up a two-way synch so we can move over to darcs gradually? It's not really practical for us to move over in one go, we've simply accumulated too many dependencies on CVS, and there are lots of people using the repo with CVS. If we had a two-way synch, we can experiment with darcs non-destructively.
I believe so. I haven't tried that myself yet, but I think tailor.py supports it. To do that though, we should really identify a permanent home for the canonical fptools darcs repo. I'm not really set up to provide accounts for those that would need write access, and I don't want to be the gatekeeper (I suspect nobody else wants that either <g>). If cvs.haskell.org is up to the task, that would be an ideal location IMHO. I haven't yet convinced tailor.py to work with the pserver for fptools, so if it can access the repo on the local filesystem, that would be ideal. Plus, one could then cron it to run frequently. I'll volunteer to do the work to figure out how to do this and get it installed if someone wants to install darcs 1.0.2 on that box and give me a spot to plonk down the darcs repo. It uses about 355M, including the pristine and working trees. _darcs itself is 240M. And, urm, 20,000+ inodes will be needed to be safe :-) (df -i will show those) My brief look at cvs.h.o shows that /home has plenty of space free. cvs.h.o has only 256M of RAM. On a repo this size, darcs sometimes uses more than that. However, with the exception of periodic checkpointing, I think we could avoid those RAM-intensive operations on the server side. The other benefit of having it on cvs.haskell.org is that it can be cronned to run fairly frequently (say, every 15 minutes) to help minimize the possibility of conflicts.
Off the top of my head, a few other things we need before we can even think of switching over:
- split up the full fptools repo into pieces (as we discussed on #haskell).
I gave that some thought before I started. Several things occured to me: * There are quite a few commits in fptools that modify multiple projects (more than anyone estimated at first, I think) * The conversion process took a long time, so it may be best to convert it all at once and then split it up (~1 week * n projects == more time than I have to invest) * There were several "great renames" in the tree. Tracking the entire history of an invidual project across those would be difficult at best. Now, having said that, I did keep the request in mind. I figure that this big repo can be split up into smaller ones at any time after the CVS mirroring is stopped. For each smaller one, the process would be: 1. Branch (darcs get) the master repo 2. Delete all the files that don't apply to the smaller project 3. Rename the smaller project's files as appropriate 4. Checkpoint here Because darcs get hardlinks patches, this wouldn't be as costly to disk as it might seem, and still preserves the history of the smaller project. I'm about to write a new mail to darcs-users about my observations of darcs' performance on this repo. The summary is that the day-to-day operations are still fairly fast and my ext2 server is holding up far better than I expected.
- a web interface to the repo
If you mean darcs.cgi, that should be trivial enough to set up on whatever the permanent host is. I don't run it on my server because I am very resource-limited there
- commit mails to the cvs-<blah>@haskell.org lists
I figure a cron job can do this. Every x minutes, run darcs changes -s, and send copies of never-before-seen logs to the list. Should be fairly trivial. I can do this too. (But only after the CVS gateway is disabled; otherwise, you'd get two copies for every commit) Let me know your thoughts. -- John
On 20050428T082550-0500, John Goerzen wrote:
- commit mails to the cvs-<blah>@haskell.org lists
I figure a cron job can do this. Every x minutes, run darcs changes -s, and send copies of never-before-seen logs to the list. Should be fairly trivial. I can do this too. (But only after the CVS gateway is disabled; otherwise, you'd get two copies for every commit)
I'll note here again the Fenfire project's script http://himalia.it.jyu.fi/darcs/fenfire/metacode/send_darcs_diffs.py which needs to be run from Cron. -- Antti-Juhani Kaijanaho http://antti-juhani.kaijanaho.info/ Blogi - http://kaijanaho.info/antti-juhani/blog/ Toys - http://www.cc.jyu.fi/yhd/toys/
participants (9)
-
Andre Pang -
Antti-Juhani Kaijanaho -
Erik de Castro Lopo -
Gour -
Ian Lynagh -
John Goerzen -
Shae Matijs Erisson -
Simon Marlow -
Sven Panne