Re: [darcs-users] Mac OS X issue with permissions (?)
On Tue, Jun 5, 2018 at 5:25 AM, Max Brown wrote: > Hello Darcs-Users, > > I just upgraded from version 2.3 to 2.10.1, using the Mac OS X binaries on > the website. Those contained a manfile and the main executable, which I > plopped into /usr/local/bin. > > While the main things work fine (like recording and pushing patches), there > is a permission problem with using darcs diff. > > Can someone tell me what I am doing wrong? I don't think you're doing anything wrong, I think darcs diff just doesn't work on OS X. It hasn't for quite a few years. ___ darcs-users mailing list darcs-users@osuosl.org https://lists.osuosl.org/mailman/listinfo/darcs-users
Re: [darcs-users] so long and thanks for all the darcs
By the way, I found this thread really interesting and informative, and learned some things about git and version control. So thanks for the discussion. Content-addressed storage is pretty interesting. There was actually a filesystem based on this, for Plan 9, called fossil. It was a true write-only filesystem and had some interesting properties that are somewhat reminiscent of git. The paper is a good read, like all the plan 9 papers. Another random aside, is that one of the things that broke when I ported from darcs to git is that git removed the empty directories. It turns out git doesn't support empty directories at all. Of that's due to how they implemented content-address storage and not the idea itself, but it's still a bit of an awkward side-effect, along with the more well-known "doesn't really support renames" one. ___ darcs-users mailing list darcs-users@osuosl.org https://lists.osuosl.org/mailman/listinfo/darcs-users
Re: [darcs-users] so long and thanks for all the darcs
On Sun, Mar 18, 2018 at 9:31 AM, Ben Franksen wrote: >> > We don't have a "kernel" with a stable API, >> >> git doesn't have a stable API either. I don't know about the current >> developers, but Linus basically promised that the *UI* would be >> backward compatible. Any scripts you've written will continue to >> work. The internal APIs are subject to change, though, and that's why >> there's never been a successful refactoring into a "libgit" plus CLI >> module. I don't know if it's "officially" stable, but in practice I've been relying on libgit2 for the last 4+ years (not sure how many exactly, but a long time). However, it's an independent implementation that works directly on the database, so it's really the disk format that's stable. It looks like both github and and gitlab use it as a backend now, so presumably they have plenty of attention and developers, and command line git won't be able to break it without a lot of people finding out right away. ___ darcs-users mailing list darcs-users@osuosl.org https://lists.osuosl.org/mailman/listinfo/darcs-users
Re: [darcs-users] so long and thanks for all the darcs
On Mon, Mar 5, 2018 at 2:08 AM, Ben Franksen wrote: > I have just tried this and in fact when I resume the edit all the escape > sequences are printed literally. However, the editor does react to them: > I can quit using ":q" and the garbage on the screen isn't actually put > in the log. Still a bug which I intend to fix, see > http://bugs.darcs.net/issue2572. Good deal. I know these kinds of weird terminal interaction bugs are not necessarily easy or fun to track down, but it's one of those usability details that no one notices when it works and everyone complains when it doesn't :) ___ darcs-users mailing list darcs-users@osuosl.org https://lists.osuosl.org/mailman/listinfo/darcs-users
Re: [darcs-users] so long and thanks for all the darcs
On Mon, Mar 5, 2018 at 1:19 AM, Ben Franksen wrote: > But you /can/ work in the same way with darcs: just don't (q)uit, rather > say (d)one. Then use 'darcs amend' to add more changes or 'darcs amend > --unrecord' to remove changes. There is also the --edit-long-comment > option for amend. Yes, I also often worked this way. I don't know why I didn't use it more than I did though... maybe because of: > We could improve the workflow a bit by presenting the changes in the > opposite order with 'amend --unrecord', so it acts more like an undo. Yes, I have definitely wanted exactly this feature more than once. I'm all for it. ___ darcs-users mailing list darcs-users@osuosl.org https://lists.osuosl.org/mailman/listinfo/darcs-users
Re: [darcs-users] so long and thanks for all the darcs
On Sun, Mar 4, 2018 at 2:46 AM, Ben Franksen wrote: >> There are a few other quibbles, like how obliterate -O is too slow to >> be useful, > > (perhaps we should have made --no-minimize the default?) Is that what you get when you ^C while it's working? If so, yeah I'd optimize for speed over disk usage. >> conflict markers don't label their sections, ^Z out of >> editing a commit message can badly hose the terminal, > > I guess that is on Windows (it would be ^D or rather ^C on Linux and it > works there). Our Windows support is lacking, sadly, mostly because I > have not yet managed to set up an environment where I can build and test > on Windows. Actually it's xterm on linux. I *think* I saw it on iterm2 on OS X as well. It doesn't happen with 2.10.1, and does with 2.12.5. My guess it that it has to do with how darcs prompts put the terminal into raw mode, then vim of course uses raw mode, somehow the state saving and restoring gets messed up when you ^Z out and fg back in. It's easy for me to reproduce: Record changes in darcs 2.12.5, then say yes to "add a long comment" where EDITOR=vim. Now ^Z out of vim, and then fg back. At that point, vim is in command mode, but any keys just appear literally on the screen, so there's no way to save or quit or do anything. The only way out is to kill vim from another terminal, at which point darcs finishes the record (I guess it doesn't mind that vim return nonzero?). >> and you need an >> obscure DARCS_DONT_ESCAPE_8BIT to show utf8 properly, but any complex >> tool has its share of those kind of things. > > True. Just to mention it, I fixed this particular problem some time ago > (not yet released, partly because it doesn't yet work on Windows as well > as on Linux, see below). Glad to hear :) >> And then of course that it's >> increasingly non-mainstream compared to git + github or gitlab, and >> probably causes people to think twice before getting involved. I >> dislike a monoculture too but you can only die on so many hills at >> once :) > > ;-) I have chosen to die on this one and don't expect many others to > stay at my side... and I do need a somewhat longer break every now and then. I'm glad someone is doing it, the commutative patch approach is quite nice and it should be developed. I also looked into pijul, but at the time the log command was broken and it made me think if they're still at the state where basic commands just don't work at all sometimes and no one notices then it's not yet ready to trust with a real project. I wish them luck too. WRT branches, I too like the simplicity of them just being separate repos. Maybe this just needs a wrapper command that understands the tree structure of the various branches, and then can do higher level operations across branches like pull or push them all, or visualize where they are, or whatever. At least for me making the whole thing feel lighter weight would go a long way, even if it's really the same underneath. The other thing would be making it all faster, maybe it could be lazy by default or have some way to get a COW copy without having to copy or hardlink a zillion patch files. I guess the global cache is already doing that, but it's still not sub-second, and it seems to grow with repo size. The idea of splitting the branch on a conflict is very interesting. Sometimes it seems awkward to back out if I pull a conflicting patch, so any pull can be scary. I guess it's because the conflict detritus gets mixed in with uncommitted local changes. I would not be scared if I knew that I could just delete the branch to back out. Branching history rather than mutating the present should be a familiar concept to Haskell programmers :) Also, I know this is external tool territory, but there really needs to be some nicer way to merge than looking for 'v's and trying to figure out what all those *s and =s mean and what happened and what changed. Even just documentation examples of how to integrate with a 3-way merge tool could help a lot. While I'm at the wishing well it would be nice if interactive record could save its state so you don't have to redo it all if you quit out of it. This could get the effect of git's staged commit but without the complicated "cache" layer, just a file with the record state that you can use to resume if you want. I know I've whinged about this before, but it *is* nice how in git I can do add -p, then quit, make some more changes, add some more hunks, etc. and commit at the end. ___ darcs-users mailing list darcs-users@osuosl.org https://lists.osuosl.org/mailman/listinfo/darcs-users
Re: [darcs-users] so long and thanks for all the darcs
On Sat, Mar 3, 2018 at 6:26 PM, Karl O. Pinc wrote: > I use darcs, git, and mercurial; git only > for non-technical reasons. I'm pretty much on-board > with the git critique of: > https://stevebennett.me/2012/02/24/10-things-i-hate-about-git/ Can't say I disagree much with that either :) > This being so, I'm curious why a darcs user would choose > git over mercurial. Honestly, because I don't know mercurial. I should fix that someday. My impression is that it's like git but with a more sensible command line interface, and has an elaborate plugin system with tons of extensions (which nice in a way but scary in another way). Is there a document for mercurial from the perspective of darcs out there? ___ darcs-users mailing list darcs-users@osuosl.org https://lists.osuosl.org/mailman/listinfo/darcs-users
[darcs-users] so long and thanks for all the darcs
I recently switched my main project from darcs to git. I'm mentioning it because I feel like it might be one of the larger and older darcs repos out there, with the exception of darcs itself (10 years, 6328 patches, around 140k lines of haskell). The reasons were that I wanted to use both diff and whatsnew (2.10 has broken diff, >2.10 has working diff (I think), but very slow whatsnew), and I wanted in-repo branches. Separate repos directories have their advantages, but practically speaking it's nice to able to back up everything with a single git push --all, and being really easy to stick notes and partial work into a new branch means I tend to actually do that. I have lost work due to not bothering to push a branch to hub.darcs.net... my own fault, but ease of use is important. There are a few other quibbles, like how obliterate -O is too slow to be useful, conflict markers don't label their sections, ^Z out of editing a commit message can badly hose the terminal, and you need an obscure DARCS_DONT_ESCAPE_8BIT to show utf8 properly, but any complex tool has its share of those kind of things. I think the main thing is the feeling that darcs development is not moving very quickly, so bugs and regressions take a long time to be noticed, and then to be fixed. And then of course that it's increasingly non-mainstream compared to git + github or gitlab, and probably causes people to think twice before getting involved. I dislike a monoculture too but you can only die on so many hills at once :) But I still think darcs is and has always been great, and I'm sad to go, so I wanted to thank everyone involved with its development. I will surely miss darcs every time I have to do a rebase just to pull a patch, or have to stash things just to merge, or silently lose changes due to weird interactions between working set, cache, and repo, or forced pushes due to rebase mess silently destroying commits, etc. The darcs export process was mostly trouble-free, except it still seems to have some bugs related to case-insensitive filesystems, but redoing it on linux solved the problem. So thanks for that feature as well, it's one of the things that gave me confidence to stick with darcs for as long as I did. So that's my final experience report and "exit interview", I hope it's interesting and useful! ___ darcs-users mailing list darcs-users@osuosl.org https://lists.osuosl.org/mailman/listinfo/darcs-users
Re: [darcs-users] preparing a 2.14 release
I vote for just revert the patch, assuming it's still easy to do. The "release discipline" I'm familiar with is to always revert any regressions as soon as possible, unless they are fixing something more important. And if I read the patch notes correctly, it seems like this was a case where the documentation said it would detect conflicts but it never did, and it took years for anyone to notice, so it seems not so critical. Once the regression is fixed then there original patch can be amended with a performance fix at leisure. On Tue, Dec 12, 2017 at 4:00 PM, Guillaume Hoffmann wrote: > I agree, we should also fix this problem for 2.14, thanks for recalling us :) > > I still do not know what we should do about it in little time, > implementing _darcs/conflicts seems to me the best solution but also > just reverting the change would be a good temporary solution until we > get it right. > > Guillaume > > 2017-12-12 16:06 GMT-03:00 Evan Laforge : >> Can we revert the patch that causes issue 2541? For me, the slowdown >> is a strong enough reason to either compile a 2.10 for linux (which I >> recall is tricky because you have to also install an old ghc) or >> migrate off darcs. I haven't done either yet because I mostly work on >> OS X and the 2.10 binary is still available. In any case, I think the >> feature added "look for conflicting files" which makes everything so >> slow is not worth making whatsnew so slow over. >> >> I'm surprised there hasn't been a bigger fuss about this, maybe there >> are no medium sized darcs repos left? >> >> On Mon, Dec 11, 2017 at 6:34 AM, Guillaume Hoffmann >> wrote: >>> Hi all, >>> >>> there has been a recent breakage of darcs 2.12 build on stackage, and >>> fixing it would require bumping several dependencies upper bounds, >>> including base. >>> >>> Rather than doing that, I find more economical to prepare a release of >>> Darcs 2.14. For this we need to fix the following: >>> >>> * windows compilation (broken by Ben's encoding changes) >>> * make dependency on graphviz optional (hence the command `darcs show >>> dependencies`) (see http://bugs.darcs.net/patch1626 ) >>> >>> There are still bundles to review and tons of bugs to fix, but they >>> are not blockers for a 2.14.0 release. >>> >>> Opinions? >>> >>> Guillaume >>> ___ >>> darcs-users mailing list >>> darcs-users@osuosl.org >>> https://lists.osuosl.org/mailman/listinfo/darcs-users ___ darcs-users mailing list darcs-users@osuosl.org https://lists.osuosl.org/mailman/listinfo/darcs-users
Re: [darcs-users] preparing a 2.14 release
Can we revert the patch that causes issue 2541? For me, the slowdown is a strong enough reason to either compile a 2.10 for linux (which I recall is tricky because you have to also install an old ghc) or migrate off darcs. I haven't done either yet because I mostly work on OS X and the 2.10 binary is still available. In any case, I think the feature added "look for conflicting files" which makes everything so slow is not worth making whatsnew so slow over. I'm surprised there hasn't been a bigger fuss about this, maybe there are no medium sized darcs repos left? On Mon, Dec 11, 2017 at 6:34 AM, Guillaume Hoffmann wrote: > Hi all, > > there has been a recent breakage of darcs 2.12 build on stackage, and > fixing it would require bumping several dependencies upper bounds, > including base. > > Rather than doing that, I find more economical to prepare a release of > Darcs 2.14. For this we need to fix the following: > > * windows compilation (broken by Ben's encoding changes) > * make dependency on graphviz optional (hence the command `darcs show > dependencies`) (see http://bugs.darcs.net/patch1626 ) > > There are still bundles to review and tons of bugs to fix, but they > are not blockers for a 2.14.0 release. > > Opinions? > > Guillaume > ___ > darcs-users mailing list > darcs-users@osuosl.org > https://lists.osuosl.org/mailman/listinfo/darcs-users ___ darcs-users mailing list darcs-users@osuosl.org https://lists.osuosl.org/mailman/listinfo/darcs-users
Re: [darcs-users] Proposal: make DARCS_DONT_ESCAPE_8BIT=1 the default
All I can say is it's about time! This has been one of those traps where darcs messes things up and you have to go find some obscure variable to fix it for as long as I've used darcs. On Tue, Sep 26, 2017 at 3:48 PM, Ben Franksen wrote: > ...now that the encoding stuff is in screened, this seems to be a > sensible move. It means that darcs will show non-ASCII text (in meta > data as well as in content) in un-escaped form in the user's locale > encoding. Things like control characters are still escaped by default as > are spaces at the end of a line. > > I guess this is what people expect from a tool like darcs nowadays. I > also guess that few users even know about this environment setting. And > casual users or newcomers will tend to think that encodings other than > ASCII still aren't well supported in darcs. > > Of course, the user's locale encoding might not be the one in which a > patch was recorded, in which case the text might look strange. But with > the wide-spread use of UTF8 these days this is becoming less and less > likely (and there remains the option to explicitly set the environment > variable to 0). > > I have a (simple) patch for that but I want to give users and devs the > opportunity to voice any objections. > > Cheers > Ben > > ___ > darcs-users mailing list > darcs-users@osuosl.org > https://lists.osuosl.org/mailman/listinfo/darcs-users ___ darcs-users mailing list darcs-users@osuosl.org https://lists.osuosl.org/mailman/listinfo/darcs-users
[darcs-users] OS X darcs 2.10.1 diff: darcs: /usr/bin/diff: fileAccess: permission denied (Operation not permitted)
I just wrote up this bug but then discovered it doesn't affect 2.12, so maybe it's not worth chasing down. Still though, 2.10.1 is the latest version with an OS X binary download, and compiling darcs yourself involves downloading a huge amount of haskell infrastructure, so I'd guess OS X people will mostly be on 2.10. And of course 2.12 has that slow whatsnew so for me at least 2.10 is better, except for: Here's another darcs bug that's come up: Lately every time I use 'darcs diff' I get this error. I tried putting on all the verbose flags I could and it still won't tell me what it's actually trying to run: % d diff --last=1 --debug --verbose --timings Wed Aug 2 18:10:40 PDT 2017: Beginning identifying repository . Wed Aug 2 18:10:40 PDT 2017: Done identifying repository . Wed Aug 2 18:10:40 PDT 2017: Identified darcs-2 repo: /Users/elaforge/src/seq/solkattu-group Wed Aug 2 18:10:41 PDT 2017: Reading patch file: patch 82a516548d00143cb282ff9b2d54b72e5f708f21 Author: qdun...@gmail.com Date: Wed Aug 2 15:40:36 PDT 2017 * solkattu: extract tempo to its own argument Wed Aug 2 18:10:41 PDT 2017: I'm doing copyFileUsingCache on patches/000858-246ed887d585d50bbdeb0f3e2036e01ccd1baa8a3b007af3efadfdfd41e520be Wed Aug 2 18:10:41 PDT 2017: About to gzFetchFilePS from "/Users/elaforge/src/seq/solkattu-group/_darcs/patches/000858-246ed887d585d50bbdeb0f3e2036e01ccd1baa8a3b007af3efadfdfd41e520be" Wed Aug 2 18:10:41 PDT 2017: gzFetchFilePS done. darcs: /usr/bin/diff: fileAccess: permission denied (Operation not permitted) --store-in-memory doesn't help. Even --diff-command='echo %1 %2' gives the same result. /usr/bin/diff exists, and has permissions 0755, and works fine, so I don't know who exactly is getting that error. Probably the best course is to fix the slow whatsnew, and then update the OS X binary on http://darcs.net/Binaries ___ darcs-users mailing list darcs-users@osuosl.org https://lists.osuosl.org/mailman/listinfo/darcs-users
Re: [darcs-users] whatsnew -l much slower in darcs 2.12.5
Thanks for the response. Let me know if you need any help with reproduction.
On Mon, Jul 31, 2017 at 10:45 AM, Guillaume Hoffmann
wrote:
> Hi Evan,
>
> thanks for reporting the issue and showing the output of strace, it
> seems there is something going on with the cache system. I will try to
> look at this soon.
>
> Guillaume
>
> 2017-06-25 2:00 GMT-03:00 Evan Laforge :
>> I've been using the darcs 2.10.1 binary available for OS X, but I
>> recently tried 2.12.5 and whatsnew -l is much slower. E.g.:
>>
>> % time ~src/hs/darcs-2.12.5/dist/build/Darcs/darcs w -l
>> ...
>> ~src/hs/darcs-2.12.5/dist/build/Darcs/darcs w -l 2.48s user 0.47s
>> system 101% cpu 2.909 total
>>
>> % time darcs w -l
>> ...
>> darcs w -l 0.13s user 0.04s system 96% cpu 0.181 total
>>
>> Restricting to a single file, e.g. 'darcs w -l X' is still very slow.
>> Without -l, both old and new are fast. This is on a medium sized
>> repo:
>>
>> % darcs show repo
>> Format: hashed, darcs-2
>> Root: /Users/elaforge/src/seq/main
>> Pristine: HashedPristine
>> Cache: thisrepo:/Users/elaforge/src/seq/main,
>> cache:/Users/elaforge/Library/Caches/darcs, repo:hub.darcs.net:karya
>> boringfile Pref: boring
>> Default Remote: hub.darcs.net:karya
>>Num Patches: 5692
>>
>> The slowdown is also visible in the linux version. On linux, I tried
>> running with strace, and it seems to be constantly running
>> mkdir("..cache/patches"), stat(".../.cache/patches"), then
>> link("_darcs/patches/...", ".cache/patches") -> EEXIST, repeating for
>> many different patches. It doesn't seem to get stuck at any time,
>> just be processing lots of patches. wc on the strace output shows
>> 130k lines. So maybe that's related?
>>
>> Anyone else see this?
>> ___
>> darcs-users mailing list
>> darcs-users@osuosl.org
>> https://lists.osuosl.org/mailman/listinfo/darcs-users
___
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users
[darcs-users] whatsnew -l much slower in darcs 2.12.5
I've been using the darcs 2.10.1 binary available for OS X, but I
recently tried 2.12.5 and whatsnew -l is much slower. E.g.:
% time ~src/hs/darcs-2.12.5/dist/build/Darcs/darcs w -l
...
~src/hs/darcs-2.12.5/dist/build/Darcs/darcs w -l 2.48s user 0.47s
system 101% cpu 2.909 total
% time darcs w -l
...
darcs w -l 0.13s user 0.04s system 96% cpu 0.181 total
Restricting to a single file, e.g. 'darcs w -l X' is still very slow.
Without -l, both old and new are fast. This is on a medium sized
repo:
% darcs show repo
Format: hashed, darcs-2
Root: /Users/elaforge/src/seq/main
Pristine: HashedPristine
Cache: thisrepo:/Users/elaforge/src/seq/main,
cache:/Users/elaforge/Library/Caches/darcs, repo:hub.darcs.net:karya
boringfile Pref: boring
Default Remote: hub.darcs.net:karya
Num Patches: 5692
The slowdown is also visible in the linux version. On linux, I tried
running with strace, and it seems to be constantly running
mkdir("..cache/patches"), stat(".../.cache/patches"), then
link("_darcs/patches/...", ".cache/patches") -> EEXIST, repeating for
many different patches. It doesn't seem to get stuck at any time,
just be processing lots of patches. wc on the strace output shows
130k lines. So maybe that's related?
Anyone else see this?
___
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users
