[darcs-users] a grumpy SVN user tries darcs

[Tupshin Harper]

zooko at zooko.com wrote:

>`anthony is a good hacker.  He is the release manager for Python, and the
>author of Shtoom.  He is also impatient and critical.  He is very familiar
>with CVS and SVN, and he (finally) decided to try darcs in order to pull some
>patches from me.  The following is an IRC transcript of what happened,
>excerpted to contain only the darcs-relevant parts of the conversation.
>
>The most frustrating thing for me in this experience was that curl (perhaps
>because of a new version of curl that I recently installed?) won't recognize
>my self-signed TLS cert.  This is obviously a problem in curl rather than in
>darcs, but I don't want to report it to the curl developers because I am so
>tired of trying to explain the relative merits of the key-continuity public
>key model vs. the public-key-infrastructure model...
>
>Regards,
>
>Zooko
>  
>
Thanks for the feedback...some comments inline.

-Tupshin

><zooko> Get a binary of ghc, or just get a binary of darcs.
><`anthony> sweet. the docs for ghc point to
>	   http://www.haskell.org/ghc/docs/latest/html/building/building-guide.html,
>	   which doesn't exist.
>  
>
That link works fine for me.

><zooko> Well, if binaries were ahead of sources on the darcs front page, you'd
>	be a lot less irritated at this point, right?
>  
>
Seems like a minor issue at worst since the binaries are linked directly 
from the front page.

><zooko> Fuck.  New cert isn't acceptable to libcurl any more than old cert.
>	ARGH.
>  
>
Looks like the best way to resolve this problem is to add your CA to 
curl-ca-bundl.crt which is in /usr/share/curl/curl-ca-bundle.crt (in 
debian at least). This should allow curl and libcurl to use your CA. 
This is definitely a bad usability issues on the libcurl side of things.

><`anthony> It should focus first on just _using_ it locally, e.g. checkin,
>	   patch, diff, update and the like. _then_ get into the remote
>	   repository fun.
>  
>
Well...it covers the basics of local usage first (initialize, add, 
record, whatsnew), and then gets into multiple repo usage, which covers 
both multiple local repos as well as remote usage. I think this order is 
exactly right, as the distributed nature of darcs (along with arch, bk, 
etc.) means that multiple repo interaction is fundamental to the use of 
the software. Note, that you can't branch (as in CVS) without multiple 
repos, so it's pretty important to cover moving patches between repos 
early on.

><`anthony> http://darcs.net/manual/node4.html#SECTION00410000000000000000
><zooko> That sounds good to me.
><zooko> I'm basically sending this entire transcript to the darcs mailing list
>	at this point.  ;-)
><`anthony> At the moment it goes 'new repo', 'adding files', 'modify, see
>	   local changes', 'checkin', then off into the world of repository
>	   sharing.
><`anthony> This is not a useful step.
>  
>
It definitely is.

><zooko> Hm.
><`anthony> Also - I expect that in "getting started" there might be a
>	   discussion of concepts.
><zooko> But, I think that those ones you listed *are* the basics of just using
>	it locally.
><zooko> new repo, adding files, modify, see local changes, checkin.
><`anthony> I will admit that I am impatient, but when I see the docs have a
>	   "getting started", I go there first.
>  
>
Try "Introduction"

><`anthony> argh. the ring.wav and ringing.wav patch are most frustrating.
><zooko> I guess "darcs diff" doesn't do something very nice with binary files?
><`anthony> not even close ;)
>  
>
Any suggestions for what it could do better for binary files?