Re: Libraries in the repo
On 27/08/2009 11:37, Sittampalam, Ganesh wrote: Simon Marlow wrote: Simon Marlow wrote: I suggest if we stick with the independent repo approach that we have some automation to check that changes are indeed getting pushed upstream. [snip unhelpful suggestion from me] Yes, it tells you that you've screwed up, rather than telling you that you're about to screw up, which would be much more convenient. After you've screwed up it might be too late to fix it, due to conflicts with upstream. Can you arrange that the only way that patches can get into the branch is via darcs pull --intersectionupstream repo ? That's an interesting idea, I'd forgotten about --intersection. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Libraries in the repo
On 27/08/2009 11:25, José Pedro Magalhães wrote: Hello, On Wed, Aug 26, 2009 at 18:15, Simon Marlow marlo...@gmail.com mailto:marlo...@gmail.com wrote: * Boot libraries are of several kinds: - INDEPENDENT: Independently maintained (e.g. time, haskeline) - COUPLED: Tightly coupled to GHC, but used by others (base) - SPECIFIC: Totally specific to GHC (e.g. template-haskell, DPH) Does syb fall under INDEPENDENT or COUPLED? In any case, as the syb maintainer, I'd favor (1) too. I'd say at this stage it's INDEPENDENT. Thanks for the feedback! Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Libraries in the repo
On 28/08/2009 10:05, Simon Marlow wrote: On 27/08/2009 11:37, Sittampalam, Ganesh wrote: Simon Marlow wrote: Simon Marlow wrote: I suggest if we stick with the independent repo approach that we have some automation to check that changes are indeed getting pushed upstream. [snip unhelpful suggestion from me] Yes, it tells you that you've screwed up, rather than telling you that you're about to screw up, which would be much more convenient. After you've screwed up it might be too late to fix it, due to conflicts with upstream. Can you arrange that the only way that patches can get into the branch is via darcs pull --intersectionupstream repo ? That's an interesting idea, I'd forgotten about --intersection. I have a script that works as a prehook (below). Unfortunately it doesn't work on darcs.haskell.org, I think because we only have darcs 1.0.9 there, and it is ignoring my prehook. Can anyone think of a good reason not to upgrade darcs to 2.3.0 on darcs.haskell.org? I can think of 3 reasons to do so: - this script, for preventing accidental divergence from upstream - faster pushes, due to transfer-mode - hide those annoying Ignore-this: x messages Cheers, Simon #!/bin/sh -e # checkupstream.sh # Only allow applying of patches that are also in this upstream repository: UPSTREAM=$1 # echo DARCS_PATCHES_XML = $DARCS_PATCHES_XML # Take $DARCS_PATCHES_XML and turn it into a list of patch hashes # suitable for looping over. hashes=`echo $DARCS_PATCHES_XML | sed 's|/patch|/patch\n|g' | sed -n '/hash/p' | sed s|^.*hash='\([^']*\)'.*$|\1|` # echo hashes: $hashes # For each patch, try pulling the patch from the upstream repo. If # the patch is not upstream, then fail. for p in $hashes; do if darcs pull --match=hash $p $UPSTREAM --xml --dry-run | grep $p /dev/null; then echo Patch $p is upstream; ok else echo Patch $p is not upstream! exit 1 fi done exit 0 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Libraries in the repo
On Fri, 2009-08-28 at 11:42 +0100, Simon Marlow wrote: Can anyone think of a good reason not to upgrade darcs to 2.3.0 on darcs.haskell.org? I can think of 3 reasons to do so: - this script, for preventing accidental divergence from upstream - faster pushes, due to transfer-mode - hide those annoying Ignore-this: x messages By the way, people who regularly work with the ghc repos (at least on Linux) and who are thinking of upgrading to darcs-2.3.0 should heed this advice: Use darcs get to get your repos again. Not remotely, just locally. This switches them from darcs1 traditional format to darcs1 hashed format. If you do this, then darcs whatsnew gets ~4 times quicker. If you do not do this, then darcs whatsnew gets ~100 times slower. All times measured on Linux, local ext3 filesystem, ghc testsuite repo. All times are the second of two runs to allow for OS caching. The results may well be quite different on a different file systems, like Windows NTFS. Perhaps someone can suggest a way of doing this using the ./darcs-all script, that would not mess up what the default push/pull address is. Of course doing a get means the copy doesn't have the changes from the working directory. As far as I know darcs currently does not provide a way to do an inplace upgrade to the faster format. I've emailed the darcs list to raise this issue, that: 1. we get no warning or advice from darcs that we should switch format 2. that there is not a really convenient way of doing the switch Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
