On Sunday 25 February 2007 18:12, Malcolm Wallace wrote:

Ross Paterson writes:

...

...

* I think that Hugs should finally be moved to darcs instead of CVS

No objection, but I think it takes a bit of extra effort to make the history look nice, e.g. check

http://darcs.haskell.org/darcsweb/darcsweb.cgi?r=parsec;a=summary

This is just a matter of which options you give to 'tailor', the conversion utility. In particular, you can tell it to use the first line of the CVS commit message as the name of the darcs patch, with the remaining lines from CVS as the "long" message in darcs.

It would be very nice if you could do that conversion for the Hugs repository. I think that http://darcs.haskell.org/hugs98 will be the right place. The only thing is: Is "98" a good suffix when we will move to Haskell'? Hmmm... Anyway, having a darcs repository soon would be great.

The main non-automated issue when converting is the need to create/steal a darcs-all script, and maybe a utility to fix executable permissions for fresh checkouts.

I can do this after the conversion. Furthermore, I think that we can (and should) have a unified version of these scripts for GHC, Hugs and nhc98. Cheers, S.

On Thursday 15 March 2007 17:48, Malcolm Wallace wrote:

I have been trying all day today to persuade either tailor or cvs2darcs to do the conversion, and failed miserably. I believe there is some kind of character-encoding problem causing tailor to misinterpret the contents of the CVS repo, leading to only 16 patches of history, instead of 2393. Meanwhile cvs2darcs gives me a completely empty darcs repo (after a very long time, and lots of warning messages).

Does the Hugs CVS repo contain any strange encoding in commit messages? Neither ASCII nor UTF-8 seems to be accepted, whereas Latin-1 is accepted but gives incorrect results.

Do you have a log of what you did in detail? I don't have a black belt in using tailor or cvs2darcs, but perhaps I have some time in the next few days to play around a bit... Cheers, S.

Further investigation show that the problematic commit is probably: date: 2006-08-10 19:31:47 +0200; author: ross; state: Exp; split off generation of the compatibility libraries into tools/make_oldlib If I see this correctly, tools/make_oldlib was introduced then, and removed a few months later: date: 2006-11-24 14:12:16 +0100; author: ross; state: dead; lines: +0 -0; remove unused script I am not sure why this should be a problem, but playing around with tailor's start-revision strongly suggests this. A bit clueless, S.

Hmmm, if I see things correctly, tailor has problems whenever it encouters a CVS file in "state: dead", i.e. when a file was removed in its past. If the CVS repo contains such a file, one gets only those changesets which are younger than that removal. I've played around a bit with a local copy of the hugs98 repo, and whenever I've removed such file from the repo itself, tailor stopped at the next dead file, and so on, and so on... Is there a trick I'm not aware of? Having dead (and perhaps resurrected) files in a CVS repo is not *that* uncommon. :-( Cheers, S.

Perhaps this is the happy end of a looong story... :-) After lots of failures I think I've successfully converted the hugs repo to darcs, using tailor-0.9.26 and the attached configuration file. The new repo URL is (not surprisingly) http://darcs.haskell.org/hugs98, and it can be browsed via darcsweb, too: http://darcs.haskell.org/darcsweb/darcsweb.cgi. (The latter URL is a bit ugly, see http://www.w3.org/Provider/Style/URI. Something like http://darcs.haskell.org/darcsweb would be much better, but I don't have the permissions to fix the apache2.conf. Who can change this?) Some notes from the trenches: * In general, tailor seems to be a cool piece of SW, but given all the problems I had, I would label it "beta", still. * The bleeding edge version of tailor from darcs is completely broken regarding files which have been removed at some point in the past, one simply gets incomplete changesets, but no warnings/errors/... * The bleeding edge version even has to be modified to run at all with newer python versions (the 'U' modifier when opening files for writing is forbidden). * The latest released version I could find (0.9.27) is incompatible with the python installed on darcs.haskell.org (some 'sort' API change, I guess). * Version 0.9.19 fails to handle the conversion Latin1 => UTF8. * Version 0.9.26 seems to work, at least I hope so. Please give the new repo a try, and if everything seems to be OK, we should somehow disable the CVS repo to avoid confusion. A darcs-all script is on the way (in the next few days). Cheers, S.

On Saturday 24 March 2007 17:08, Ross Paterson wrote:

Looks good to me. Just a few old directories not removed:

dotnet/lib/System lib libraries/Hugs

If you can do something about those, let's switch.

This is funny: When I do a 'darcs get' for the repo, my local copy has those 3 empty directories, but the directories on the server are non-empty... Confused, S.

OK, let's try the next iteration... :-) I've re-converted the repo from scratch, tagged it (including a checkpoint), removed the empty directories, and finally removed the CVS keywords. Things look OK to me now, and http://darcs.haskell.org/darcsweb/darcsweb.cgi?r=hugs98;a=summary is OK, too, I think. Before we turn off Hugs' CVS, I'll have to adapt the build system, add a darcs-all, test building an RPM, etc. Nevertheless, if someone spots a flaw in the conversion up to now, please yell. Small note: tailor seems to use "darcs remove" when a file is removed from CVS, but this does not remove the file itself. Therefore the "empty" diretories stay populated, although their contents are not versioned anymore. I don't know if this is a bug in tailor or supposed to work that way. Anyway, it's a bit surprising to the unsuspecting user... Cheers, S.

On Sunday 25 March 2007 18:37, Ross Paterson wrote:

It looks good to me too. I'm in favour of a quick switch.

I am not sure when I can add the final touch (darcs-all etc.), but it should be in the next few days. Perhaps we should make the CVS repo read-only already and update the web pages? Cheers, S.

On Sunday 25 February 2007 17:48, Ross Paterson wrote:

Most of the Hugs packagers have been using version numbers like 200609 for some time now, so we ought not to move to small numbers.

Hmmm, so what is your exact suggestion for our numbering scheme for released versions and snapshot versions?

[...] For releases, I think Hugs should move away from fetching snapshots of libraries and tools from repositories, and use tarballs of numbered releases instead, now that we have a home for those. For library development, I find it convenient to share a single copy of the library sources between GHC and Hugs builds.

Using released packages only for Hugs releases is a good thing, although GHC and nhc98 are not doing it currently (at least not via their scripts, I suspect that there is some manual intervention). I am not exactly sure how to handle this: Should we have a table of explicit package versions to get, or is there some canonical URL for the latest released version of a package? And how exactly should the sharing work? And what about nhc98?

...

* I think that Hugs should finally be moved to darcs instead of CVS, the current mix of version control systems is a bit obscure and we need darcs for the libraries, anyway. I have no former experience in doing this conversion, but I think others on this list have, so I'd prefer not doing this for myself (or at least get some hint/tricks/... from others who have done it before).

No objection, but I think it takes a bit of extra effort to make the history look nice, e.g. check

http://darcs.haskell.org/darcsweb/darcsweb.cgi?r=parsec;a=summary

Exactly this "bit of extra effort" is unclear to me, so I'd prefer if somebody else would do the conversion. Cheers, S.

On Monday 26 February 2007 10:52, Ross Paterson wrote:

On Sun, Feb 25, 2007 at 06:19:55PM +0100, Sven Panne wrote:

...

Hmmm, so what is your exact suggestion for our numbering scheme for released versions and snapshot versions?

YYYYMM and YYYYMM.DD?

Fine with me. The date should probably be the build date in a first step. GHC'S build system is currently trying to be clever by asking darcs about the latest change and using that date, but this a bit of a hack at the moment and doesn't e.g. take into account the packages IIRC.

...

Using released packages only for Hugs releases is a good thing, although GHC and nhc98 are not doing it currently (at least not via their scripts, I suspect that there is some manual intervention). I am not exactly sure how to handle this: Should we have a table of explicit package versions to get, or is there some canonical URL for the latest released version of a package?

For releases, we'd want a table of versions; we'd also want that in the release notes.

I think a file containing lines like core base ??? core Cabal ??? extra OpenGL ??? extra http://www.cs.york.ac.uk/fp/darcs/polyparse ??? ... might do the trick, with the first column describing the status of the package and the second column the place to get the bleeding edge version of it (non-http: repositories can be calculated via the repository for hugs itself, see the darcs-all script for GHC, nhc98 lacks this feature). The tricky part is the third column, describing the released version to use for release builds. I guess we should use hackage somehow, but currently I fail to see how... :-( Any suggestions? Cheers, S.

On Monday 26 February 2007 13:18, Ross Paterson wrote:

Package name+version determines the URL of the tarball stored in HackageDB, e.g. http://hackage.haskell.org/packages/archive/OpenGL/OpenGL-2.1.tar.gz

and we can just assume that all packages of interest are there.

Can one safely assume that http://hackage.haskell.org/packages/archive/PACK/PACK-VER.tar.gz untars into a PACK-VER directory containing that package? I hope that this is the case. So our package description file can look like this: core base 2.1 core haskell98 1.0 extra http://www.cs.york.ac.uk/fp/darcs/polyparse ftp://ftp.cs.york.ac.uk/pub/haskell/polyparse/polyparse-1.0.tar.gz extra OpenGL 2.1 ... Earlier you've mentioned some sharing of libraries. Could you elaborate a bit how this should work in detail? I only have a very vague idea, and I am not sure if this is a must or only a nice-to-have. Cheers, S.