On Thu, Aug 28, 2008 at 04:31:16PM +1000, Manuel M T Chakravarty wrote:
Ian Lynagh:
On Mon, Aug 18, 2008 at 12:21:47PM +1000, Manuel M T Chakravarty
wrote:
From what you are saying, it seems that one advantage of git (in-
place branch switching) is not going to be useful to GHC in any case
Ian Lynagh:
On Mon, Aug 18, 2008 at 12:21:47PM +1000, Manuel M T Chakravarty
wrote:
From what you are saying, it seems that one advantage of git (in-
place branch switching) is not going to be useful to GHC in any case
Yes.
(because we use nested repositories).
That does make it harder,
Isaac see third
FWIW, I started a wiki page that tries a direct comparison between Darcs and
Git:
http://hackage.haskell.org/trac/ghc/wiki/GitForDarcsUsers
Some mappings are simple, some are more complicated and will require
adopting a different workflow. I still recommend
I personally don't know Git, and while I'm sure I'll be learning at
some point, I'm always nervous about learning a VCS on something I
care about, as mistakes can go quite wrong.
If I can lend you (or someone else) a hand don't hesitate to contact me.
(I'm not a git guru though..)
With git you
Using merge you also get a more accurate reflection of the project
history, i.e. you can see that the two branches were being developed
independently.
Timestamps will be preserved so not all information is lost..
Marc
___
Glasgow-haskell-users
Sorry for being a git n00b, but does using merge mean that we need to use
in-place branch switching (which you earlier said won't work well for ghc
anyways)?
You have to kind of branches : local ones and remote ones.
remote ones represent the state of remote ones. The only way I know of
On Mon, Aug 18, 2008 at 12:21:47PM +1000, Manuel M T Chakravarty wrote:
From what you are saying, it seems that one advantage of git (in-place
branch switching) is not going to be useful to GHC in any case (because we
use nested repositories).
Manuel
I don't agree. I feel it's
Git 1.6.0 was just released [1]. Might be of interest given the
current discussion.
I cherry picked some highlights that might matter to us:
* Source changes needed for porting to MinGW environment are now all in the
main git.git codebase.
* even more documentation pages are now accessible via
On Mon, Aug 18, 2008 at 09:20:54PM +1000, Ben Lippmeier wrote:
Ian: Did this problem result in Intel CC / GCC register allocator
freakouts?
Have you got me confused with someone else? I don't think I've ever used
Intel CC.
Thanks
Ian
___
On Mon, Aug 18, 2008 at 12:21:47PM +1000, Manuel M T Chakravarty wrote:
From what you are saying, it seems that one advantage of git (in-
place branch switching) is not going to be useful to GHC in any case
Yes.
(because we use nested repositories).
That does make it harder, but the main
On Mon, Aug 18, 2008 at 12:28:03PM +1000, Manuel M T Chakravarty wrote:
does using merge mean that we need to use in-place branch switching
No; when you git pull (the equivalent of darcs pull -a) it will pull
and merge the changes (unless you ask it to rebase them instead of
merging them).
Manuel M T Chakravarty wrote:
From what you are saying, it seems that one advantage of git
(in-place branch switching) is not going to be useful to GHC in any case
(because we use nested repositories).
As far as I can tell, in-place branches are not a lot of use to us compared
to just
Duncan Coutts wrote:
On Fri, 2008-08-15 at 15:12 +0100, Ian Lynagh wrote:
On Fri, Aug 15, 2008 at 11:12:20AM +1000, Manuel M T Chakravarty wrote:
Moreover, as I wrote a few times before, some reasons for switching in
the first place are invalidated by not having the core libraries in
git,
On 18/08/2008, at 8:13 PM, Simon Marlow wrote:
So would I usually, though I've had to turn down cc flags to get
darcs
to build on ia64 before (SHA1.hs generates enormous register
pressure).
We should really use a C implementation of SHA1, the Haskell version
isn't buying us anything
Gregory Wright:
On Aug 14, 2008, at 9:12 PM, Manuel M T Chakravarty wrote:
Moreover, as I wrote a few times before, some reasons for switching
in the first place are invalidated by not having the core libraries
in git, too. For example, one complaint about darcs is that it
either doesn't
From what you are saying, it seems that one advantage of git (in-
place branch switching) is not going to be useful to GHC in any case
(because we use nested repositories).
Manuel
Ian Lynagh:
On Fri, Aug 15, 2008 at 01:01:08PM +0100, Max Bolingbroke wrote:
2008/8/15 Isaac Dupree [EMAIL
Ian Lynagh:
On Fri, Aug 15, 2008 at 04:24:12PM +0100, Ian Lynagh wrote:
On Fri, Aug 15, 2008 at 05:09:55PM +0200, Thomas Schilling wrote:
On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh [EMAIL PROTECTED] wrote:
One way that it is worse is that you will get a lot more automatic
merge commits when
On Sat, Aug 16, 2008 at 12:21 AM, Thomas Schilling
[EMAIL PROTECTED] wrote:
you don't use local branches?
I do. I like to keep a clean linear history on top of the upstream
repo. So I might do work in a topic branch, rebase it on my master
branch which is synced with upstream and then push.
--
On Fri, 2008-08-15 at 15:12 +0100, Ian Lynagh wrote:
On Fri, Aug 15, 2008 at 11:12:20AM +1000, Manuel M T Chakravarty wrote:
Moreover, as I wrote a few times before, some reasons for switching in
the first place are invalidated by not having the core libraries in
git, too. For
Hi Manuel,
On Aug 14, 2008, at 9:12 PM, Manuel M T Chakravarty wrote:
Moreover, as I wrote a few times before, some reasons for switching
in the first place are invalidated by not having the core libraries
in git, too. For example, one complaint about darcs is that it
either doesn't
Manuel M T Chakravarty wrote:
Thomas Schilling:
Are you advocating for ease of use by new developers or for existing
developers? Current GHC hackers have to learn Git anyways and know
Darcs already. Library patches still have to be recorded separately,
so it would be a bit weird, but not much
2008/8/15 Isaac Dupree [EMAIL PROTECTED]:
So let's figure out how it would work (I have doubts too!) So, within the
directory that's a git repo (ghc), we have some other repos, git (testsuite)
and darcs (some libraries). Does anyone know how git handles nested repos
even natively?
You can
On Fri, Aug 15, 2008 at 11:12:20AM +1000, Manuel M T Chakravarty wrote:
Moreover, as I wrote a few times before, some reasons for switching in
the first place are invalidated by not having the core libraries in
git, too. For example, one complaint about darcs is that it either
doesn't
On Fri, Aug 15, 2008 at 01:01:08PM +0100, Max Bolingbroke wrote:
2008/8/15 Isaac Dupree [EMAIL PROTECTED]:
So let's figure out how it would work (I have doubts too!) So, within the
directory that's a git repo (ghc), we have some other repos, git (testsuite)
and darcs (some libraries). Does
On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh [EMAIL PROTECTED] wrote:
One way that it is worse is that you will get a lot more automatic
merge commits when you pull changes from the central repo into a repo
in which you have local commits. I don't think that there is anything
bad about these,
On Fri, Aug 15, 2008 at 05:09:55PM +0200, Thomas Schilling wrote:
On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh [EMAIL PROTECTED] wrote:
One way that it is worse is that you will get a lot more automatic
merge commits when you pull changes from the central repo into a repo
in which you have
On 16/08/2008, at 00:12, Ian Lynagh wrote:
On Fri, Aug 15, 2008 at 11:12:20AM +1000, Manuel M T Chakravarty
wrote:
Moreover, as I wrote a few times before, some reasons for switching
in
the first place are invalidated by not having the core libraries in
git, too. For example, one
On Fri, Aug 15, 2008 at 04:24:12PM +0100, Ian Lynagh wrote:
On Fri, Aug 15, 2008 at 05:09:55PM +0200, Thomas Schilling wrote:
On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh [EMAIL PROTECTED] wrote:
One way that it is worse is that you will get a lot more automatic
merge commits when you pull
If you have lots of local changes (e.g. the sorts of long-running branch
that gives darcs 1 problems), then you need to use merge. If you use
rebase then you might end up with lots of conflicts to manually resolve.
Using merge gives you automatic merge commits, If you think these are
ugly
On Thu, Aug 14, 2008 at 12:10 PM, Isaac Dupree [EMAIL PROTECTED] wrote:
And I wonder why (it sounds like) Git doesn't have tools to do some kind of
smart cherrypicking, using a heuristic to decide which patches in a branch
are definitely dependencies of the cherry-picked patch. In any case, I
2008/8/15 Ian Lynagh [EMAIL PROTECTED]:
You can explicitly tell Git about nested Git repos using
http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html.
This essentially associates a particular version of each subrepo with
every version of the repo that contains them, so e.g.
On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh [EMAIL PROTECTED] wrote:
One way that it is worse is that you will get a lot more automatic
merge commits when you pull changes from the central repo into a repo
in which you have local commits. I don't think that there is anything
bad about these,
you don't use local branches?
On Sat, Aug 16, 2008 at 12:04 AM, Johan Tibell [EMAIL PROTECTED] wrote:
On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh [EMAIL PROTECTED] wrote:
One way that it is worse is that you will get a lot more automatic
merge commits when you pull changes from the central
Max Bolingbroke:
Then, adding complexity, git branches are normally done by
switching in-place. So how does this interact with VCS like darcs
that
doesn't have a concept of in-place switching of branches?
Since we will set up Git to ignore the contents of the Darcs repos, it
will simply
On Wed, Aug 13, 2008 at 04:35:42PM +1000, Manuel M T Chakravarty wrote:
Rebuilding with stage1 was already needed to build GHC with a builtin
readline. In general, it is a bad idea to build distributed binaries
of Haskell programs with the *bootstrap compiler*. It must be done
with
On Wed, Aug 13, 2008 at 04:19:37PM +1000, Manuel M T Chakravarty wrote:
Simon Marlow:
Manuel M T Chakravarty wrote:
To be honest, if you ask me, I'd go back to the old makefile based
system and remove Cabal from everywhere except building of the
library packages.
I wouldn't object to
Duncan Coutts:
On Mon, 2008-08-11 at 13:57 +0100, Simon Marlow wrote:
- Performance. darcs2 regressed in performance for many
operations we
commonly use. I've submitted some measurements for some things,
but
it's pretty easy to find your own test cases: things like darcs
add,
Duncan Coutts wrote:
Turns out that the reason for slow darcs whatsnew is ghc bug #2093
http://hackage.haskell.org/trac/ghc/ticket/2093
because getSymbolicLinkStatus is broken on 32bit systems in 6.8.2 it
means that the 'stat' optimisation does not work so darcs has to read
the actual
Iavor Diatchki wrote:
I also don't think that the darcs model has much to offer over git, in
fact I find that it lacks some useful features (not counting a
reliable implementation). Examples include good support for
branching, and being able to easily determine the version of the
software that
Hi
So I suggest we propose moving all the core packages to git, and we
translate all those for which nobody objects to the change. For the others,
we'll keep them in darcs and live with the pain.
Does this mean my (now the communities) FilePath library is going to
get moved over to git?
I
Neil Mitchell:
If it really makes the life easier for people who are having lots of
VCS pain at the moment, then its hard to object. But many of the
comments in this discussion, about how everyone is going to flock to
GHC just as soon as it switches to Git, seem overly optimistic. I
think GHC is
Are you advocating for ease of use by new developers or for existing
developers? Current GHC hackers have to learn Git anyways and know
Darcs already. Library patches still have to be recorded separately,
so it would be a bit weird, but not much harder, really.
On Fri, Aug 15, 2008 at 1:59 AM,
Thomas Schilling:
Are you advocating for ease of use by new developers or for existing
developers? Current GHC hackers have to learn Git anyways and know
Darcs already. Library patches still have to be recorded separately,
so it would be a bit weird, but not much harder, really.
I am arguing
Simon Marlow:
Manuel M T Chakravarty wrote:
To be honest, if you ask me, I'd go back to the old makefile based
system and remove Cabal from everywhere except building of the
library packages.
I wouldn't object to dropping the use of Cabal for other tools in
the build tree; the reasons
Ian Lynagh:
On Tue, Aug 12, 2008 at 10:20:14AM +1000, Manuel M T Chakravarty
wrote:
To be honest, if you ask me, I'd go back to the old makefile based
system and remove Cabal from everywhere except building of the
library
packages.
Manuel
PS: Just for some more collateral damage. Did
Simon Peyton-Jones:
2. The version control system (VCS)
GHC needs core libraries without which it cannot be built. It is
obviously highly desirable that a developer can build GHC with just
one VCS, which suggests that the core libraries should be in git too.
But those same core libraries are
On Wed, Aug 13, 2008 at 2:49 AM, Manuel M T Chakravarty
[EMAIL PROTECTED] wrote:
Ian, I completely agree with you. I love the darcs vcs model, too.
However, we have three discussions here:
(1) Do we want darcs vcs model?
Except Thomas Schilling, who seems to be dead set to get rid of
| FWIW, I started a wiki page that tries a direct comparison between
| Darcs and Git:
|
|http://hackage.haskell.org/trac/ghc/wiki/GitForDarcsUsers
Very helpful thank you!
Simon
___
Glasgow-haskell-users mailing list
Manuel M T Chakravarty wrote:
Everybody who contributes to the boot/core libraries needs to validate
their patches. If the GHC version of the libraries is in git, then all
library code needs to be validated against the git version of the
libraries before it can enter the master repository.
Norman Ramsey wrote:
I also see repeatedly that the distinction between the build system
and packaging system is blurry: both have to know about build targets,
dependencies, and so on.
At the time of the wonderful GHC Hackathon in Portland, where the GHC
API was first introduced to the public,
Matthias Kilian wrote:
I mean the GHC-specific template used for building the Makefile
(Distribution/Simple/GHC/Makefile.in) and the function `makefile`
in Distribution/Simple/GHC.hs (this function even spills out some
some make rules in addition to what's in Makefile.in, which looks
very wrong
Manuel wrote:
| It is worth pointing out that I *never* validate against ghc head
when
| I commit to the core libraries.
Sorry, but I think the only reason its halfway acceptable is that
Malcolm didn't break the GHC build yet. If he does, I'll be
screaming as loudly as for anybody
We (GHC HQ) are still learning the transition to wider participation
in building and hacking on GHC, which we *very much* welcome. Bear
with us if we don't get it right first time. We're trying!
And I very much like the steps I've seen recently in explaining
what you're doing (sometimes even
As someone who is not contributing to the core libraries I find a few
things in this discussions a bit puzzlng.
- Why does NHC98 break so often? Is it because people are checking in
code that is not Haskell 98 compatible?
- It seems to me that implementations share libraries using CPP. At
least
Claus Reinke wrote:
Perhaps it would be useful for GHC HQ to have a GHC project
blog,
Actually we have talked about doing that, and it's highly likely we'll set
one up in due course. I think it's worth letting the current discussion(s)
run their course and then we'll have a set of
On Wed, Aug 13, 2008 at 12:21 PM, Malcolm Wallace
[EMAIL PROTECTED] wrote:
- Why does NHC98 break so often? Is it because people are checking in
code that is not Haskell 98 compatible?
Yes, there is a bit of that. Also, as you point out, there is quite a lot
of CPP conditionally compiled
On Wed, 2008-08-13 at 16:19 +1000, Manuel M T Chakravarty wrote:
In a sense, it was an interesting experiment and it should still be
useful to the development of Cabal. In fact, I see no reason why the
experiment cannot be continued on a branch. Who knows, maybe Cabal is
sufficiently
I don't think that is the right policy. Everybody (including Malcolm)
should validate.
If you contribute code to the linux kernel, comprehensive testing of
the code is a requirement, too.
The analogy is flawed. It is like asking the developers of _gcc_ to
ensure that the Linux kernel
On Wed, Aug 13, 2008 at 1:52 PM, Malcolm Wallace
[EMAIL PROTECTED] wrote:
I don't think that is the right policy. Everybody (including Malcolm)
should validate.
If you contribute code to the linux kernel, comprehensive testing of
the code is a requirement, too.
The analogy is flawed. It
I think an even better analogy is probably comparing it to developer
of GCC changing the libc implementation of another compiler or vice
versa.
Our shared libraries do not belong to any one compiler. They are joint
creations, with a lot of community (non-compiler-hacker) involvement.
Excerpts from Johan Tibell's message of Wed Aug 13 02:09:00 -0500 2008:
I'm also in favor of the switch to Git. The Git model has proved to be
both more productive and more reliable. And the interface, as far as
I'm concerned, is *better*.
Seconded. The git documentation these days I find is
On Wed, Aug 13, 2008 at 1:54 AM, Malcolm Wallace
[EMAIL PROTECTED] wrote:
Manuel wrote:
| It is worth pointing out that I *never* validate against ghc head when
| I commit to the core libraries.
Sorry, but I think the only reason its halfway acceptable is that Malcolm
didn't break the
On Wed, Aug 13, 2008 at 09:03:34AM +0100, Simon Marlow wrote:
Yes, it relies only on the Cabal metadata, but the output is a
Makefile only useful for building GHC.
Ok, this statement is plainly not true, since I can use 'cabal makefile'
to build any package outside of the GHC build tree.
On Mon, 2008-08-11 at 13:57 +0100, Simon Marlow wrote:
- Performance. darcs2 regressed in performance for many operations we
commonly use. I've submitted some measurements for some things, but
it's pretty easy to find your own test cases: things like darcs add,
darcs whatsnew,
Manuel M T Chakravarty wrote:
As far as I am concerned, building GHC is turning into a big mess. We
discussed ways to improve it again, BUT I'd rather not see it getting
any messier before it gets better. Hence, please let's have a complete
plan that we are convinced will work before making
On 12 Aug 2008, at 01:35, Manuel M T Chakravarty wrote:
Ah, good point! Changing ghc to git means *all* developers of boot
libraries need to use git *regardless* of what repo format the boot
libraries are in. After all, they need to validate against the
current ghc head before pushing.
| It is worth pointing out that I *never* validate against ghc head when
| I commit to the core libraries.
I think that's perfectly reasonable for the reasons you explain.
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
On Mon, 2008-08-11 at 14:29 +0200, Thomas Schilling wrote:
On 11 Aug 2008, at 13:00, Duncan Coutts wrote:
It's not clear to me that we've really bothered to find out. The last
evaluation in relation to ghc that I'm aware of was prior to the 2.0
release. My impression is that we've all
On Tue, Aug 12, 2008 at 10:20:14AM +1000, Manuel M T Chakravarty wrote:
To be honest, if you ask me, I'd go back to the old makefile based
system and remove Cabal from everywhere except building of the library
packages.
Manuel
PS: Just for some more collateral damage. Did anybody
Friends
| I see more and more workarounds for workarounds for an unmaintainable
| (and unusable) build system, and after the latest discussions about
| git vs. darcs, maintaining GHC-specific branches of libraries etc.,
| I think I'll just drop maintainership from all GHC-related OpenBSD
|
A metacomment:
As a lurker, and a reader of other languages' mail groups, I just wanted to
complement you GHC folks on the quality of your discussion. You're discussing
an issue that people clearly have strong opinions about, yet you've all
remained polite and respectful and kept the
Norman Ramsey wrote:
At the time of the wonderful GHC Hackathon in Portland, where the GHC
API was first introduced to the public, I urged Simon PJ to consider
taking ghc --make and generalising it to support other languages.
I still think this would be a good project.
As well as supporting
On Tue, Aug 12, 2008 at 11:59:37AM +0100, Simon Marlow wrote:
Well, at least the Makefile creation was a step (the first step?)
into the wrong direction, IMHO. I'll run a GHC build to get some
of those generated Makefiles and followup on cvs-ghc, but for a
starter, Cabal shouldn't know
On Tue, Aug 12, 2008 at 10:29:03PM +0200, Matthias Kilian wrote:
Basically, the .cabal file is just converted into some other format
that may be included by another Makefile.
Oops! I again read your (SimonM's) proposal on changing Cabal and
the GHC build system in exactly this way. Sorry for
Hello,
On Tue, Aug 12, 2008 at 5:49 PM, Manuel M T Chakravarty
[EMAIL PROTECTED] wrote:
Ian, I completely agree with you. I love the darcs vcs model, too.
However, we have three discussions here:
(1) Do we want darcs vcs model?
Except Thomas Schilling, who seems to be dead set to get
Brandon S Allbery wrote:
On 2008 Aug 10, at 20:17, Norman Ramsey wrote:
For the last year I have been hoping to make 'a new darcs-like
thing,
with a real theory founding it' an important part (one of three) of
a
grant proposal in distributed computing. So you can see I am in
favor
of
Thomas Schilling wrote:
(I am also no longer convinced that Darcs'
automatic patch dependency calculations are
actually a good idea. Just because two patches
don't touch the same files, doesn't mean they
aren't semantically dependent. Take for
example monadification patches, which are
On 11 Aug 2008, at 12:38, Sittampalam, Ganesh wrote:
Thomas Schilling wrote:
(I am also no longer convinced that Darcs'
automatic patch dependency calculations are
actually a good idea. Just because two patches
don't touch the same files, doesn't mean they
aren't semantically dependent.
On 11 Aug 2008, at 13:00, Duncan Coutts wrote:
It's not clear to me that we've really bothered to find out. The last
evaluation in relation to ghc that I'm aware of was prior to the 2.0
release. My impression is that we've all complained about the darcs v1
problems (justly) but spent the most
-Original Message-
From: Thomas Schilling [mailto:[EMAIL PROTECTED]
Sent: 11 August 2008 12:18
To: Sittampalam, Ganesh
Cc: Manuel Chakravarty; Don Stewart; Ian Lynagh; Simon Peyton-Jones; GHC
Users Mailing List
Subject: Re: Version control systems
Thomas Schilling wrote:
On 11 Aug
Duncan Coutts wrote:
It's not clear to me that we've really bothered to find out. The last
evaluation in relation to ghc that I'm aware of was prior to the 2.0
release. My impression is that we've all complained about the darcs v1
problems (justly) but spent the most effort investigating things
kili:
On Mon, Aug 11, 2008 at 04:17:59PM +0100, Simon Marlow wrote:
[...]
As for Cabal - we had a thread on cvs-ghc last week, and as I said there
we'd love to hear suggestions for how to improve things, including wild
and crazy ideas for throwing it all away and starting again. However,
On Sat, Aug 9, 2008 at 10:44 PM, Roman Leshchinskiy [EMAIL PROTECTED]wrote:
Maybe investing some time in fixing the most obvious darcs problems would be
a better solution?
We're working on that over at Darcs HQ, but there is no guarantee that we'd
come close to fixing the problems within the
On 2008 Aug 10, at 2:12, Jason Dagit wrote:
On Sat, Aug 9, 2008 at 10:44 PM, Roman Leshchinskiy [EMAIL PROTECTED]
wrote:
Maybe investing some time in fixing the most obvious darcs problems
would be a better solution?
We're working on that over at Darcs HQ, but there is no guarantee
Malcolm Wallace:
I seriously hope the plan is to move all *core* libraries
(including
GHC's cabal repo) etc over to git, too.
* one build system
* one vcs
This is a chance to make a big step towards accessibility, let's
make that step.
Ultimately, I don't think git would make ghc
Jason Dagit:
On Sat, Aug 9, 2008 at 10:44 PM, Roman Leshchinskiy [EMAIL PROTECTED]
wrote:
Maybe investing some time in fixing the most obvious darcs problems
would be a better solution?
We're working on that over at Darcs HQ, but there is no guarantee
that we'd come close to fixing the
On Sat, Aug 09, 2008 at 06:56:23PM -0400, Norman Ramsey wrote:
* I violently agree with whomever (Don? Malcolm?) said that the
Haskell community will prosper to the degree that we have *one*
build system and *one* version-control system. And when the build
system or
On Sun, Aug 10, 2008 at 02:16:25PM +1000, Manuel M T Chakravarty wrote:
Duncan Coutts:
I don't especially relish having to learn another vcs tool or raising
the bar for contributions to Cabal either (we have lots of people who
make small one-off contributions).
I don't think it matters
On Sat, Aug 09, 2008 at 09:30:52PM +0100, Malcolm Wallace wrote:
The libraries question is a difficult one. We have made a lot of
effort over the last 5 years to build infrastructure and code that is
shared and portable across multiple implementations of the language.
Is this the
I had my share of problems with Darcs; working on the GHC API I
constantly have to avoid conflicts. My temporary workaround is to
not update at all. Maybe switching to Darcs 2 format would help
here, but there are other issues.
I initially converted GHC to Git to be able to more easily
Hello,
I think that we should switch the repositories of the core libraries
to git too, not just because GHC is switching, but simply because git
is a more reliable RCS. It seems that this does not prevent other
implementations from using them---the code in the repositories will be
still the
On Sat, Aug 09, 2008 at 06:56:23PM -0400, Norman Ramsey wrote:
* Our long-term goal should be to get the *entire* Haskell
development community to agree on a version-control system---one
that is not darcs. We should expect this process to take several
years, and we
On 2008 Aug 10, at 20:17, Norman Ramsey wrote:
For the last year I have been hoping to make 'a new darcs-like thing,
with a real theory founding it' an important part (one of three) of a
grant proposal in distributed computing. So you can see I am in favor
of spending money to create a
Ian Lynagh:
On Sun, Aug 10, 2008 at 02:16:25PM +1000, Manuel M T Chakravarty
wrote:
Duncan Coutts:
I don't especially relish having to learn another vcs tool or
raising
the bar for contributions to Cabal either (we have lots of people
who
make small one-off contributions).
I don't
Thomas Schilling:
I had my share of problems with Darcs; working on the GHC API I
constantly have to avoid conflicts. My temporary workaround is to
not update at all. Maybe switching to Darcs 2 format would help
here, but there are other issues.
I initially converted GHC to Git to be
On Sat, 2008-08-09 at 15:46 +1000, Manuel M T Chakravarty wrote:
Raising the bar for developers to contribute to a project has been
proven to be a very bad idea many times. Let's not take GHC down that
path.
I don't especially relish having to learn another vcs tool or raising
the bar
Duncan Coutts wrote:
On Sat, 2008-08-09 at 15:46 +1000, Manuel M T Chakravarty wrote:
Raising the bar for developers to contribute to a project has been
proven to be a very bad idea many times. Let's not take GHC down that
path.
I don't especially relish having to learn another vcs tool
On Sat, Aug 09, 2008 at 03:46:50PM +1000, Manuel M T Chakravarty wrote:
Don was excited about getting more people to look at the source
when it is in git (see the comments he posted from reddit).
I am skeptical that this initial excitement and cloning will translate
into more developers.
dons:
chak:
Ian Lynagh:
On Fri, Aug 08, 2008 at 12:04:15PM +1000, Manuel M T Chakravarty
wrote:
I seriously hope the plan is to move all *core* libraries (including
GHC's cabal repo) etc over to git, too. In other word, everything
that you need to build the development version
As a very part-time, temporarily inactive GHC developer I will offer
some opinions which should carry no weight:
* When I saw the announcement, I cheered! Last fall, I lost 2 weeks
of a 9-week visit to darcs hell. While the alleged features may
be alluring, the software simply doesn't
1 - 100 of 118 matches
Mail list logo
