| Time |
S |
Nick |
Message |
| 00:07 |
|
kowey |
just did rm -rf / (but stopped it in time) |
| 00:07 |
|
lambdabot |
kowey: You have 1 new message. '/msg lambdabot @messages' to read it. |
| 00:16 |
|
lispy |
kowey: ah, that's bad! |
| 00:17 |
|
kowey |
hmm... silly IRC client doesn't show me what's going on in #darcs |
| 00:17 |
|
lispy |
hmm...I think I once saw a way to disable that command with bash |
| 00:18 |
|
lispy |
I think it worked by creating a bash function that didn't allow things like, rm -rf /, rm -rf ~/ but allowed other invocations of rm |
| 00:19 |
|
kowey |
i was doing some makefile hacking |
| 00:19 |
|
kowey |
(wxhaskell actually) |
| 00:19 |
|
kowey |
and one of the clean targets had a variable mis-set |
| 00:19 |
|
kowey |
I think I lost the first two and a half applications in /Applications |
| 00:19 |
|
lispy |
:( |
| 00:20 |
|
lispy |
on your mac? |
| 00:20 |
|
kowey |
(that's a convenient first thing to have in /... hopefully no important . files) |
| 00:20 |
|
kowey |
yeah |
| 00:20 |
|
kowey |
btw, what do you have as the first couple of entries? |
| 00:20 |
|
lispy |
on my mac? |
| 00:20 |
|
kowey |
(yeah, if it's not too indiscreet) something, something, then Adobe Reader on mine |
| 00:20 |
|
lispy |
i'm at work right now, so no macs near by |
| 00:20 |
|
kowey |
oh ok |
| 00:21 |
|
lispy |
is researching issue tracking software that also does project management |
| 00:21 |
|
lispy |
we have none, but we need something. |
| 00:22 |
|
kowey |
does trac fit into this category? |
| 00:22 |
|
lispy |
I'm not sure, I put it on the list to look at. |
| 00:23 |
|
lispy |
I'm currently considering, JIRA, FogBugz, Trac and what we use currently for tracking customer issues, EnterpriseWizard |
| 00:24 |
|
kowey |
zooko was extolling the virtues of trac(+darcs) on the tracker just today |
| 00:25 |
|
kowey |
http://bugs.darcs.net/issue491 |
| 00:25 |
|
lambdabot |
Title: Issue 491: switch bug tracking to trac+darcs - Darcs bug tracker |
| 00:29 |
|
lispy |
hmm...the search engine in trac is not so good, and for a non-google searchable site that is not so good |
| 00:30 |
|
lispy |
It's not clear from Zooko's email if trac provides per user and per project management though. |
| 00:32 |
|
idnar |
why isn't the site google searchable? |
| 00:32 |
|
lispy |
idnar: it would be for the company I work at |
| 00:32 |
|
lispy |
this is not darcs related, I got off topic |
| 00:32 |
|
idnar |
oh, sorry, I didn't read back enough |
| 00:32 |
|
kowey |
staggers off to bed |
| 00:32 |
|
lispy |
sorry for any confusion :) |
| 00:32 |
|
idnar |
I guess trac's search isn't that great |
| 00:33 |
|
idnar |
it's just a simple text search |
| 00:33 |
|
idnar |
there's a separate ticket query interface that's more powerful, though |
| 00:34 |
|
idnar |
I'm not sure what you mean by per user and per project management, either |
| 00:35 |
|
idnar |
there's a whole slew of trac plugins in various states of brokenness that do various things, so you may be able to assemble the functionality you need, even if it's not part of the Trac core |
| 00:35 |
|
lispy |
Suppose we have 5 projects and 5 developers. Each developer might work on any of the 5 projects or not at all on some of them. I would like to know how much time each developer is obligated to (estimate through tickets) on each project and total for each developer. |
| 00:36 |
|
lispy |
Both estimated time remaning per project and per developer and time spent |
| 00:37 |
|
idnar |
ah, I don't know anything about that |
| 00:37 |
|
idnar |
but take a look around http://trac-hacks.org/ |
| 00:37 |
|
lambdabot |
Title: Trac Hacks - Plugins Macros etc. - Trac |
| 00:37 |
|
idnar |
(as well as the main trac site) |
| 00:37 |
|
lispy |
okay, I'm looking at the trac FAQ right now |
| 00:38 |
|
lispy |
It does seem that trac either supports it, or a plugin does |
| 00:38 |
|
lispy |
so that means I can't yet exclude it from the summary I'm generating |
| 00:38 |
|
lispy |
(which is good, because it's a cheap solution) |
| 00:41 |
|
lispy |
another thing I'm not clear about is the ratio of trac to repositories |
| 00:41 |
|
lispy |
Do you have a different trac instance for each repository? |
| 00:41 |
|
idnar |
that's the way I use it |
| 00:42 |
|
idnar |
I'm not sure what the status is of multi-project trac instances, either |
| 00:42 |
|
lispy |
that would be a bit of a show stopper in our use case scenario |
| 00:43 |
|
lispy |
Only one installation is required, then for each project create an Environment (using trac-admin <fooproj> initenv). They will be separate projects, all handled by the same installation of Trac. |
| 00:44 |
|
lispy |
Okay, it's still in the running :) |
| 00:44 |
|
idnar |
hmm |
| 00:44 |
|
idnar |
well, depends on what you mean |
| 00:44 |
|
idnar |
a trac "environment" is what I call a trac instance |
| 00:44 |
|
idnar |
it's a completely separate database, configuration file, etc. |
| 00:44 |
|
lispy |
Oh, well maybe I misread their FAQ |
| 00:44 |
|
lispy |
:( |
| 00:45 |
|
idnar |
although you fairly easily run them all from the same deployment, and share auth, and so on |
| 00:45 |
|
lispy |
So separate users? |
| 00:45 |
|
idnar |
but for example, the permissions on each environment will be independent |
| 00:45 |
|
idnar |
even if you share the password file across them all |
| 00:45 |
|
idnar |
although that can be a good thing; user A has access to project A's env, but not project B |
| 00:45 |
|
idnar |
(etc. |
| 00:45 |
|
idnar |
) |
| 00:45 |
|
idnar |
trac doesn't have such fine-grained permissions within a particular environment |
| 00:46 |
|
lispy |
Yeah, the fact that you'd have to look at each project to manage a given developer is bad |
| 00:47 |
|
lispy |
We have lots of projects that each developer is work on at a given time |
| 00:49 |
|
idnar |
http://trac.edgewall.org/wiki/[…]rehensiveSolution |
| 00:50 |
|
lambdabot |
Title: TracMultipleProjects/ComprehensiveSolution - The Trac Project - Trac, http://tinyurl.com/2jug4k |
| 00:50 |
|
idnar |
(I haven't used any of this, I'm just searching the web *g*) |
| 00:52 |
|
lispy |
idnar: yeah, my only complain there is that it's still alpha or beta, so I don't want to recommend my company use it |
| 00:57 |
|
idnar |
yeah |
| 00:57 |
|
lispy |
It's too bad their not done, I like trac. |
| 00:57 |
|
lispy |
they're* |
| 01:02 |
|
lispy |
Hm...I'm not sure the time tracking is very good. |
| 01:02 |
|
lispy |
That's one thing we really like about JIRA |
| 05:38 |
|
manveru |
does anyone know an approximate for the release of darcs2? |
| 06:14 |
|
lispy |
manveru: I don't think on has been set |
| 06:14 |
|
lispy |
manveru: have you tried the pre-release? |
| 06:15 |
|
manveru |
lispy: well, i'm trying it |
| 06:15 |
|
manveru |
actually, i'm trying the darcs version of darcs :) |
| 06:15 |
|
manveru |
darcs-unstable, it's called i think |
| 06:16 |
|
manveru |
i'm not too happy about how things work in mercurial or git... and would love to continue using darcs |
| 06:18 |
|
manveru |
but it's hard if there is only a pre-release and i have no idea how many changes are still coming |
| 06:19 |
|
manveru |
and there is no way to go from a darcs2 repo to a darcs1 repo for compatibility |
| 06:20 |
|
lispy |
Hmm...I can't say for 100% certain, but I think things will be added not changed |
| 06:20 |
|
lispy |
Plus, darcs1 repo can be used by darcs2 and upgraded later |
| 06:20 |
|
lispy |
manveru: what features of darcs2 are you using at the moment? |
| 06:30 |
|
manveru |
lispy: none... i don't know of its features |
| 06:30 |
|
manveru |
what i'm interested in is speed and stability |
| 06:32 |
|
lispy |
manveru: you should read this: http://wiki.darcs.net/DarcsWiki/DarcsTwo |
| 06:32 |
|
lambdabot |
Title: DarcsTwo - DarcsWiki |
| 06:33 |
|
manveru |
lispy: i did |
| 06:33 |
|
manveru |
but i don't see anything called feature there |
| 06:34 |
|
manveru |
my current problem with darcs is that with a history of ~2000 patches it's too slow to work with |
| 06:38 |
|
manveru |
_darcs is now around 18MB, while the actual content is around 3.1MB |
| 06:38 |
|
lispy |
manveru: the features are all explained there, I was just re-reading it |
| 06:39 |
|
lispy |
manveru: have you tried some of the performance enhancing features of darcs1? such as tagging and optimizing? |
| 06:39 |
|
lispy |
do they help? |
| 06:39 |
|
manveru |
they don't help |
| 06:39 |
|
manveru |
i tag around every 50-100 patches |
| 06:39 |
|
manveru |
as part of the normal release cycle |
| 06:40 |
|
lispy |
when you tag darcs tries to ignore everything older than the tag whenever it possibly can |
| 06:40 |
|
manveru |
nods |
| 06:41 |
|
manveru |
but then again you cannot really work with a partial repository |
| 06:41 |
|
lispy |
manveru: now that you have a darcs2 snap shot, have you tried creating a copy of the repository and converting the repo? Does this help performance? If not, email darcs-devel with your performance woes and I'm sure they'll get worked on. |
| 06:42 |
|
manveru |
it's hard for me to bench darcs1 vs darcs2 since the servers i'd test it with only have 1.0.9 |
| 06:42 |
|
manveru |
i might try the .deb on one machine, since it's nothing critical |
| 06:42 |
|
lispy |
could you test it locally? |
| 06:43 |
|
manveru |
locally there ain't too many problems |
| 06:43 |
|
lispy |
as the wiki says, once you convert a repo you cannot share patches with non-converted repos. So please be careful about that. |
| 06:43 |
|
manveru |
i know |
| 06:43 |
|
lispy |
what are you main problems then? |
| 06:45 |
|
manveru |
well, as i said, i'd love a real release of darcs2 :) |
| 06:45 |
|
manveru |
so we can officially move to it and most distros provide packages |
| 06:46 |
|
lispy |
I guess I'm getting confused. You said you wanted speed and stability. But then you said it's not really a problem locally. |
| 06:46 |
|
lispy |
I'm trying to figure out what operations are prohibitively slow for you on the server (or unstable). |
| 06:49 |
|
manveru |
lispy: last time i checked, `darcs pull -av` took like 2 minutes |
| 06:49 |
|
manveru |
same goes for push |
| 06:51 |
|
manveru |
lispy: http://p.ramaze.net/545 |
| 06:51 |
|
lambdabot |
Title: RaPaste |
| 06:51 |
|
manveru |
remote side is a darcs1 repo |
| 06:52 |
|
lispy |
Okay, you could try this experiment with a darcs2 binary and that repo, you can add --verbose and it should give you progress indicators |
| 06:52 |
|
lispy |
that's a new darcs2 feature |
| 06:52 |
|
lispy |
that could help us figure out where the time is spent |
| 06:52 |
|
lispy |
goes to try it out |
| 06:53 |
|
manveru |
around 10 seconds figuring out what kind of repo that is |
| 06:54 |
|
manveru |
65 seconds: "Reading inventory of repository ramaze ramaze.net:ramaze.darcs |
| 06:55 |
|
manveru |
that are the two longest operations... |
| 06:55 |
|
lispy |
could be 1) a slow connection 2) a large inventory |
| 06:55 |
|
manveru |
both |
| 06:55 |
|
manveru |
i't like 30 hops away from japan to finnland |
| 06:55 |
|
lispy |
it should be possible to split the invetory. In fact, I thought that was the default when you tag and optimize. |
| 06:55 |
|
manveru |
but mercurial still manages to do that in like 5 seconds |
| 06:56 |
|
manveru |
what exactly is the inventory? |
| 06:56 |
|
lispy |
it's essentially a list of what patches are in the repository |
| 06:57 |
|
manveru |
ok |
| 06:57 |
|
lispy |
and because you often don't need anything older than the most recent tag you can split the inventory at tags |
| 06:57 |
|
manveru |
but when i tag locally and push that patch it won't split the remote inventory |
| 06:57 |
|
lispy |
I think you're right. You'd probably have to optimize on the remote end to do that. |
| 06:57 |
|
manveru |
that might explain that... |
| 06:58 |
|
lispy |
I'd have to read up on it |
| 06:58 |
|
lispy |
goes to find the manual |
| 06:58 |
|
manveru |
hmm |
| 06:58 |
|
manveru |
no, that ain't the issue either |
| 06:59 |
|
manveru |
remote _darcs/intentories only has the patches since last tag |
| 07:00 |
|
lispy |
"# |
| 07:00 |
|
lispy |
What happens when you create a tag in the remote repository or push it over? By right, the size of the inventory should drop to zero (starting from the tag you just pushed). If not, your darcs may be slightly buggy wrt tags. darcs optimize should fix it, emptying out your inventory." |
| 07:00 |
|
manveru |
nods |
| 07:00 |
|
manveru |
it does |
| 07:00 |
|
manveru |
but it's still slow as hell |
| 07:02 |
|
lispy |
"These simple steps (tag and optimize) should resolve most of your pushing woes. If not, |
| 07:02 |
|
lispy |
1. Check to see if the same darcs operation is significantly faster when dealing with a repository that is on the same machine. 2. If you are using ssh, check to see how long a single ssh connection makes" |
| 07:02 |
|
lispy |
I think that http applise in #2 as well. |
| 07:03 |
|
lispy |
manveru: do you have some patches which are large? Darcs works best with small, say < 4k bytes, patches |
| 07:04 |
|
manveru |
i have some really old large ones |
| 07:06 |
|
lispy |
if they're old and in both repos I would expect that darcs ignores them. |
| 07:06 |
|
manveru |
i'd love to remove them somehow... since they have no influence on the current repo anymore |
| 07:07 |
|
lispy |
yeah, like darcs optimize --delete-old-history? |
| 07:07 |
|
lispy |
(that's not a real feature) |
| 07:07 |
|
manveru |
especially two patches that add and remove some binary blob |
| 07:07 |
|
manveru |
hehe |
| 07:09 |
|
lispy |
This notion of merging patches that cancel each other out, is kind of important. People ask for a variation on that theme somewhat frequently. |
| 07:09 |
|
lispy |
But, at least superficially, contradicts the purpose of version control |
| 07:10 |
|
lispy |
You should save all history, even bad history, right? |
| 07:11 |
|
lispy |
manveru: Anyway, I wish I could help more. And to answer your original question. I don't think anyone knows when the stable darcs2 will hit the shelves. The good news is that we've had several pre-releases now so hopefully we're getting closer. |
| 07:12 |
|
manveru |
:) |
| 07:12 |
|
manveru |
well, it's old history... over 1.5 years ago... |
| 07:12 |
|
manveru |
and it's not even code |
| 07:13 |
|
manveru |
anyway, thank you for your help |
| 07:14 |
|
manveru |
i would even prefer if the two patches would become one that says: here i added and removed these 5mb, kthxbai |
| 07:14 |
|
manveru |
instead of two 5mb patches |
| 07:15 |
|
manveru |
that's how old mistakes haunt you :P |
| 07:17 |
|
lispy |
yeah |
| 07:17 |
|
lispy |
I can totally relate |
| 07:17 |
|
lispy |
But, if nothing depends on that patch, maybe it can be unpulled? |
| 07:17 |
|
lispy |
but you'd have to do that in every copy... |
| 07:18 |
|
manveru |
yeah... |
| 07:18 |
|
manveru |
a distributing unpull/unrec would be wondeful :) |
| 07:18 |
|
manveru |
could've saved my ass a couple of times already |
| 07:19 |
|
lispy |
an obliterate patch could be cool |
| 07:19 |
|
lispy |
I wonder how hard that would be |
| 07:19 |
|
manveru |
anyway, watch 'ps -P `pgrep ssh`' gave me a better look at what darcs does |
| 07:19 |
|
manveru |
it reads every file in inventories... |
| 07:20 |
|
manveru |
i think that part could be optimized a lot |
| 07:20 |
|
lispy |
it downloaded each one you mean? |
| 07:20 |
|
lispy |
even though you had it locally? and this is with darcs2? |
| 07:21 |
|
manveru |
remote repo is darcs1 mind you |
| 07:21 |
|
lispy |
I wonder if this happens also with hashed repos in darcs2. |
| 07:21 |
|
lispy |
sure |
| 07:21 |
|
manveru |
but local is latest darcs2 |
| 07:22 |
|
lispy |
creating a server side copy of the repo that is hashed would be an interesting experiment. darcs1 cannot read hashed repos, but otherwise hashed is backwards compatible. |
| 07:22 |
|
manveru |
"/usr/bin/ssh -x -oForwardAgent no -oPermitLocalCommand no -oClearAllForwardings yes -q -lramaze ramaze.net scp -f ramaze.darcs/_darcs/inventories/20061017005130-24576-5b9b427a53262dd1d97f1e687b8f4e5e449160bd.gz" |
| 07:22 |
|
lispy |
That's probably confusing...what I mean is, hashed is just an optimization of darcs1 format. It doesn't change the semantics. |
| 07:22 |
|
manveru |
this is one of the commands that takes so long |
| 07:23 |
|
lispy |
manveru: can you create a copy of your repository on the server? |
| 07:23 |
|
manveru |
sure |
| 07:24 |
|
manveru |
but i cannot update the remote darcs, unless you have an ebuild around? |
| 07:24 |
|
lispy |
you can use darcs put |
| 07:24 |
|
manveru |
i can't |
| 07:24 |
|
lispy |
no? |
| 07:24 |
|
manveru |
or, do you mean darcs1 format? |
| 07:25 |
|
lispy |
you can create the hashed version locally, then use darcs put to place it on the server file system |
| 07:25 |
|
lispy |
put is the opposite of get |
| 07:25 |
|
manveru |
yes |
| 07:25 |
|
manveru |
ok, i can try hashed |
| 07:25 |
|
manveru |
thought you meant 2 |
| 07:25 |
|
lispy |
I'm curious if having a hashed repo on the server will give you better performance |
| 07:26 |
|
lispy |
manveru: also, you can use a global cache once you start using hashed |
| 07:26 |
|
manveru |
nods |
| 07:27 |
|
manveru |
converts |
| 07:27 |
|
lispy |
converts? |
| 07:27 |
|
manveru |
hmm |
| 07:27 |
|
lispy |
you're not using 'darcs convert' are you? |
| 07:27 |
|
manveru |
no go |
| 07:27 |
|
manveru |
no |
| 07:27 |
|
manveru |
get --hashed |
| 07:27 |
|
lispy |
you scared me for a second :) |
| 07:28 |
|
manveru |
:) |
| 07:28 |
|
lispy |
no go? |
| 07:28 |
|
manveru |
well, it tries to use the --hashed option remotely |
| 07:28 |
|
manveru |
which, of course, doesn't exist |
| 07:29 |
|
lispy |
okay, well you can do this weird thing |
| 07:29 |
|
lispy |
locally: darcs init --hashed foo-hashed; cd foo-hashed; darcs pull server-repo |
| 07:29 |
|
lispy |
maybe that works? |
| 07:30 |
|
lispy |
Or maybe I didn't understand what failed. THinking about that a bit more. Darcs get shouldn't have invoked the remote darcs. So I don't know why it would fail |
| 07:30 |
|
manveru |
darcs put did |
| 07:31 |
|
lispy |
Oh, interesting. |
| 07:31 |
|
lispy |
well, there is no reason why we have to use darcs to put the repo on the server |
| 07:31 |
|
manveru |
i guess darcs put only does a darcs get |
| 07:31 |
|
lispy |
you could just scp -r the whole repo to the server |
| 07:31 |
|
manveru |
sure |
| 07:31 |
|
lispy |
not sure why I thought put would be easier (I must be tired :) |
| 07:32 |
|
manveru |
that might take 30 minutes or so |
| 07:32 |
|
lispy |
okay |
| 07:32 |
|
lispy |
well, once it's there you can try watching ps again |
| 07:32 |
|
lispy |
and do a pull |
| 07:32 |
|
lispy |
see if it's faster for you |
| 07:32 |
|
manveru |
i would use unison, but the versions differ... and gentoo hasn't put in the latest yet |
| 07:32 |
|
manveru |
nods |
| 07:33 |
|
lispy |
careful with unison on darcs repos. There was a couple threads about repo corruption due to unison a long while back. |
| 07:33 |
|
manveru |
oh? |
| 07:33 |
|
lispy |
The 'sync'ing of repos can be bad if you unpull or something like that |
| 07:33 |
|
lispy |
I forget the details |
| 07:33 |
|
manveru |
right... |
| 07:34 |
|
manveru |
haven't had problems with that yet |
| 07:34 |
|
manveru |
but good to know... i usually use it for testing stuff only |
| 07:34 |
|
lispy |
It seems like you'd have to work in both copies and get them out of sync to trigger it |
| 07:35 |
|
lispy |
you should also experiment with the global cache. Did you read about that? |
| 07:35 |
|
manveru |
yes i did |
| 07:36 |
|
lispy |
I think the DarcsTwo page needs to be cleaned up |
| 07:36 |
|
lispy |
you said it was not obvious what were the new features |
| 07:36 |
|
lispy |
and it should give a timeline/estimate if possible |
| 07:39 |
|
manveru |
that would be great, yeah :) |
| 07:40 |
|
lispy |
looks like the manual needs to be updated too |
| 07:43 |
|
lispy |
manveru: good luck and good night |
| 07:45 |
|
manveru |
sleep well :) |
| 09:43 |
|
manveru |
darcs: ramaze.hashed/magic darcs standard input: openBinaryFile: does not exist (No such file or directory) |
| 09:44 |
|
manveru |
anyone got an idea how that happens? |
| 09:44 |
|
manveru |
"~/ramaze % ../bin/darcs-2.0.0pre3-linux push -av ../ramaze.hashed" |
| 09:44 |
|
manveru |
happens when pushing from darcs1 repo to hashed |
| 09:46 |
|
manveru |
the other way round it works fine, pushing/pulling from hashed to darcs1 repo |
| 09:48 |
|
manveru |
lispy: in case you're reading this, using the hashed repo takes only around 30s to push/pull and is a lot faster for local operations as well |
| 09:48 |
|
manveru |
so thank you, you saved us from mercurial :) |
| 10:50 |
|
manveru |
i notice that with the darcs version of darcs-unstable the progress is not shown |
| 10:51 |
|
manveru |
it always is at: "Identifying repository ramazeramaze.net:ramaze.hashed format", though i see it downloading patches already |
| 11:34 |
|
manveru |
http://darcs.net/cgi-bin/darcs[…]nstable/?c=browse is kinda empty :) |
| 11:34 |
|
lambdabot |
Title: darcs repository |
| 14:32 |
|
manveru |
ok... |
| 14:32 |
|
manveru |
after one hour, `get --lazy` actually finished |
| 14:33 |
|
manveru |
now i try to record, it tells me that it's: "Reading pristine 126/559 : fdc15c1fdbb7234dea323894d54a116e5fd49774" |
| 14:33 |
|
manveru |
does that mean it will d/l 126 patches? |
| 14:34 |
|
manveru |
since that's what it looks like when i look at the ssh connections... |
| 14:37 |
|
manveru |
some kind of update on the status would be nice... or a round of pong to pass the time |
| 14:41 |
|
markstos |
Good $localtime |
| 14:41 |
|
manveru |
heya |
| 14:44 |
|
manveru |
so, how about making `darcs get` a bit more intelligent? |
| 14:44 |
|
markstos |
How so? |
| 14:44 |
|
manveru |
using `scp -r` instead of scp every single patch |
| 14:45 |
|
manveru |
i'm just running a test to see the difference |
| 14:45 |
|
markstos |
With darcs 1.0.9 or Darcs 2? |
| 14:45 |
|
manveru |
unstable |
| 14:46 |
|
markstos |
Sometimes "get" uses sftp, but I'm not certain in which cases. |
| 14:46 |
|
manveru |
hmh |
| 14:46 |
|
manveru |
well, i got a bit upset when `darcs get --lazy` took an hour |
| 14:47 |
|
manveru |
with unison i have the repo in a matter of minutes |
| 14:47 |
|
markstos |
That sounds frustrating. You could always make a tarball of the project, download it, and unpack it. |
| 14:48 |
|
markstos |
Great: then you can use unison. |
| 14:48 |
|
manveru |
i could do both, but can my users? |
| 14:48 |
|
manveru |
and no, serverside unison is out of date, and i won't downgrade |
| 14:48 |
|
markstos |
If they are just users and not developers, sure. |
| 14:49 |
|
manveru |
all my users are developers |
| 14:49 |
|
manveru |
so i try to keep the barrier of entry as low as possible |
| 14:49 |
|
markstos |
What about publishing the site to pull from over https ...or just http ? |
| 14:49 |
|
manveru |
the tarball of the repo you mean? |
| 14:50 |
|
markstos |
Right, as an alternative to a one-time "darcs get" |
| 14:50 |
|
manveru |
how about making "darcs get" as effective as "hg clone"? :) |
| 14:51 |
|
markstos |
How does "hg clone" work over ssh/sftp/scp? |
| 14:51 |
|
manveru |
i can give you a breakdown when i watch it closely |
| 14:52 |
|
markstos |
Post it to darcs-devel if you like. I'm not a darcs programmer, so I could only take notes. Of course, if "darcs get" could perform better, that would be great. |
| 14:52 |
|
manveru |
indeed |
| 14:52 |
|
manveru |
i tried to switch to mercurial last week |
| 14:53 |
|
markstos |
From darcs? |
| 14:53 |
|
manveru |
nods |
| 14:53 |
|
markstos |
I hear good things about Mercurial. |
| 14:53 |
|
manveru |
yeah... |
| 14:53 |
|
manveru |
but didn't work out for us |
| 14:53 |
|
markstos |
Is it also patch-centric, like darcs is, or "tree centric" like svn and others are? |
| 14:54 |
|
markstos |
Why didn't it work out? |
| 14:54 |
|
manveru |
it's a different philosophy, kinda like darcs |
| 14:54 |
|
manveru |
but instead of patch dependency they define common parent changesets |
| 14:55 |
|
manveru |
well, the reason for the switch was the speed of darcs |
| 14:55 |
|
manveru |
we have around 2k patches now |
| 14:56 |
|
manveru |
a push/pull would take 2 minutes just to check if anything new is around |
| 14:56 |
|
markstos |
is afk for a bit |
| 14:57 |
|
manveru |
it didn't work out because it's awkward to use for someone used to the sweet user-interface of darcs |
| 14:58 |
|
manveru |
and i didn't like having 2/3 of the projects history just being useless merges without anything that changed |
| 14:58 |
|
manveru |
so now i put my hope into darcs2 |
| 14:58 |
|
manveru |
using a hashed repository at first |
| 15:01 |
|
markstos |
manveru: For our big project, we pull over http, and push over ssh. That makes a big speed difference. |
| 15:01 |
|
manveru |
oh really? |
| 15:01 |
|
markstos |
I have also tried "darcs optimize --reorder", but I'm not sure what effect that had. |
| 15:02 |
|
markstos |
Yes, but in our process patches usuall flow one direction ( alpha -> beta -> production ). |
| 15:02 |
|
manveru |
well, i tried any optimize option they had :) |
| 15:02 |
|
markstos |
However, you could use shell aliases to toggle your repo names back and forth, so you don't have to type the repo name each time. |
| 15:02 |
|
manveru |
hmh |
| 15:03 |
|
manveru |
well, i'd have to make that rake tasks then |
| 15:03 |
|
markstos |
I have explored it, but I know darcs2 can be compiled with several different http options and some of them support pipelining for further speedups. |
| 15:03 |
|
markstos |
For example, you could make a shell script "darcs_push", which calls "darcs push --no-set-default userhost:/home/repo" |
| 15:04 |
|
markstos |
And "darcs pull" would default to pulling over http (over https if you need to) |
| 15:04 |
|
manveru |
yes |
| 15:05 |
|
manveru |
so you don't use a hashed repo? |
| 15:05 |
|
markstos |
At $work, we are still waiting for darcs-2 to be released. |
| 15:06 |
|
markstos |
A key server runs an ancient FreeBSD server that would be difficult to get darcs compiled on. But, the release of darcs 2 will be a reason to upgrade the OS. :) |
| 15:07 |
|
manveru |
hmm |
| 15:07 |
|
manveru |
the binary versions seem to run just fine |
| 15:07 |
|
markstos |
I'm not aware of a binary for FreeBSD 5.1. :) |
| 15:07 |
|
manveru |
oh well :) |
| 15:07 |
|
manveru |
i don't do anything with bsd... |
| 15:08 |
|
manveru |
i thought it would be somewhat compatible with linux |
| 15:09 |
|
manveru |
hmm |
| 15:09 |
|
manveru |
how many patches do you have at work? |
| 15:10 |
|
markstos |
2000 ? About 40,000 lines of code, last time I checked. I started using darcs about when 1.0 was released. |
| 15:10 |
|
markstos |
That was perhaps 3 years ago. |
| 15:10 |
|
markstos |
It's a huge website: http://www.1-800-save-a-pet.com/ |
| 15:11 |
|
manveru |
hmh |
| 15:11 |
|
markstos |
Supporting about 1,500,000 pet searches / day now. |
| 15:12 |
|
markstos |
We use darcs to pull patches into production, and then rsync the site between several front-end web servers. |
| 15:13 |
|
manveru |
i'm only at around 12k LoC for http://ramaze.net - last time i checked was around 2000 patches |
| 15:13 |
|
manveru |
but we had an image in the repo around a year ago... which really bloats the history |
| 15:14 |
|
manveru |
ah, seems like scp is almost done |
| 15:16 |
|
markstos |
Your project looks neat. I'm bookmarking it. |
| 15:16 |
|
manveru |
heh, thanks |
| 15:16 |
|
markstos |
I help maintain the CGI::Application framework for Perl. http://www.cgi-app.org/ |
| 15:16 |
|
manveru |
i'm not in the US and not allowed to have pets... so i guess i won't save any pets |
| 15:17 |
|
manveru |
hmm, i've never done perl |
| 15:17 |
|
markstos |
:) I'm sure you'll save some ruby programmers some time, and some people some money through your open source contributions. |
| 15:17 |
|
markstos |
I've only looked at ruby. :) |
| 15:18 |
|
manveru |
well, i only see perls heritage in ruby |
| 15:19 |
|
manveru |
but when i try to actually read perl it seems so strange... |
| 15:19 |
|
manveru |
alrighty |
| 15:19 |
|
manveru |
scp -r ramazeramaze.net:ramaze.hashed . 1.21s user 8.50s system 0% cpu 38:51.73 total |
| 15:19 |
|
manveru |
darcs get --partial ramazeramaze.net:ramaze.hashed ramaze 6.08s user 4.97s system 0% cpu 59:59.34 total |
| 15:19 |
|
markstos |
There is ugly perl out there. I think Haskell looks strange, but I'm intrigued by it. |
| 15:19 |
|
markstos |
The ruby I see generally looks clean. |
| 15:20 |
|
manveru |
so... seriously |
| 15:20 |
|
manveru |
--lazy should be a _lot_ faster |
| 15:20 |
|
markstos |
Why use --partial instead of --lazy if you have darcs2 ? |
| 15:20 |
|
manveru |
forgot about it |
| 15:20 |
|
manveru |
darcs accepts both, so i kept it |
| 15:21 |
|
markstos |
Maybe you need a recent tag to limit what --lazy downloads? I'm not completely certain how it works. |
| 15:21 |
|
manveru |
i have a recent tag |
| 15:21 |
|
manveru |
only 16 patches back |
| 15:21 |
|
markstos |
There are *several* bugs that crop with --partial repos. The solution in all cases is to quit using --partial and use --lazy instead. |
| 15:22 |
|
manveru |
manverusigma ~/c % time darcs get --partial ramazeramaze.net:ramaze.hashed ramaze |
| 15:22 |
|
manveru |
--partial: hashed or darcs-2 repository detected, using --lazy instead |
| 15:22 |
|
markstos |
Hah. Cool. |
| 15:22 |
|
manveru |
i trust in that |
| 15:22 |
|
markstos |
So, you did end up using --lazy. Great. |
| 15:22 |
|
manveru |
as i said |
| 15:23 |
|
manveru |
but lazy is so much slower than a scp -r |
| 15:23 |
|
manveru |
and it's not even the full repo |
| 15:23 |
|
markstos |
You can file a "wishlist" item at bugs.darcs.net for --lazy to perform better, if you'd like. |
| 15:24 |
|
markstos |
Linking to example public repos is always helpful. |
| 15:25 |
|
manveru |
hmh |
| 15:25 |
|
manveru |
well, our repo has been through quite some stuff :) |
| 16:44 |
|
droundy |
manveru: darcs 2 is much faster if you compile with libwww (or a very recent version of libcurl) due to pipelining. |
| 16:45 |
|
manveru |
droundy: it takes 7 minutes, compared to 40 minutes for scp |
| 16:45 |
|
markstos |
droundy: why not compile with libwww by default then? |
| 16:46 |
|
droundy |
markstos: very few poeple have the libwww-dev packages installed, and it doesn't give as nice error messages. |
| 16:46 |
|
droundy |
manveru: you mean 40s for scp? |
| 16:47 |
|
droundy |
manveru: what format is your repository? |
| 16:47 |
|
manveru |
40s? |
| 16:47 |
|
manveru |
hashed format |
| 16:47 |
|
droundy |
I thougt you said lazy was slower than scp. |
| 16:47 |
|
manveru |
it is |
| 16:47 |
|
droundy |
but 7 minutes is less than 40 minutes... |
| 16:47 |
|
manveru |
droundy: http://bugs.darcs.net/msg3494 |
| 16:48 |
|
droundy |
oh, I see. you don't have darcs 2 installed as the default darcs on your server? |
| 16:48 |
|
markstos |
droundy: Do you know if libwww is packaged for distributions? Or if it is the best option, could we redistribute it? |
| 16:48 |
|
droundy |
markstos: yes, it's in debian. |
| 16:49 |
|
manveru |
droundy: no |
| 16:49 |
|
manveru |
all i could do was put the precompiled one into ~/bin and export that to PATH |
| 16:49 |
|
manveru |
but it seems like .bashrc isn't respected with ssh |
| 16:50 |
|
droundy |
manveru: try installing darcs 2 on the server, and you should get much faster get times. |
| 16:50 |
|
manveru |
it's gentoo, don't have an ebuild |
| 16:50 |
|
droundy |
you may need to stick the PATH definition in .profilerc |
| 16:50 |
|
markstos |
droundy: So we could get the debian and ubuntu packages to be built with libwww. |
| 16:50 |
|
droundy |
markstos: yes. |
| 16:50 |
|
droundy |
s/profilerc/profile/ |
| 16:51 |
|
markstos |
Is the minimum GHC version 6.4 now? I just saw 6.2 in the docs and could update it. |
| 16:52 |
|
droundy |
I think the minimum is 6.4 |
| 16:53 |
|
markstos |
droundy: so I can update the "Prerequisites" docs, is the order of preference (if they are available): libwww, libcurl, curl and wget. |
| 16:54 |
|
manveru |
droundy: no go with ~/.profile either |
| 16:54 |
|
droundy |
markstos: something like that |
| 16:54 |
|
manveru |
sometimes i wished there was a verbose version of login... |
| 16:55 |
|
droundy |
manveru: maybe your .bashrc has some sort of check whether it's an interactive session? debian's default has something like that. |
| 16:56 |
|
manveru |
droundy: you are right, indeed :) |
| 16:56 |
|
droundy |
:) |
| 16:56 |
|
manveru |
sweet |
| 16:56 |
|
manveru |
that means i will be able to push to the hashed repo now? |
| 16:58 |
|
manveru |
and it works |
| 16:58 |
|
manveru |
droundy: thanks a lot |
| 16:58 |
|
manveru |
now, on to retry darcs get... |
| 17:01 |
|
manveru |
droundy: that doesn't look any faster to me... |
| 17:02 |
|
manveru |
it's still doing things like: "scp -f ramaze.hashed/_darcs/pristine.hashed/3c441052c172fc7a3ce8134562145a43af5e40" |
| 17:02 |
|
markstos |
droundy: I hope my recent bug triaging hasn't felt overzealous. I've been more assertive about updating the status of things. I figure even if I make some different decisions, it's a net-positive, and wiki-style, anyone else can change the status if they disagree. |
| 17:02 |
|
markstos |
I think it's a good deal clearer now which bugs really need attention, and which are "deferred", if not resolved. |
| 17:03 |
|
manveru |
darcs get over ssh is still magnitudes slower than over http :| |
| 17:04 |
|
manveru |
and it never actually uses the remote darcs installation, so i doubt darcs2 makes any difference remotely |
| 17:07 |
|
manveru |
huh |
| 17:11 |
|
manveru |
http://p.ramaze.net/551 |
| 17:12 |
|
manveru |
this doesn't look good |
| 17:14 |
|
manveru |
--debug-verbose says that happens when it comes to the compressing |
| 17:14 |
|
markstos |
mail sending works automatically on Windows, without sendmail, right? |
| 17:26 |
|
droundy |
manveru: in that case it isn't making the connection. Maybe the static binary on the server is too old? You should see right at the beginning when it tries to make the ssh connection with darcs 2. |
| 17:27 |
|
droundy |
markstos: I like your bug triaging. |
| 17:27 |
|
droundy |
manveru: can I see the --debug output of your darcs get? |
| 17:28 |
|
droundy |
manveru: is darcs2 on the remote server named darcs? |
| 17:28 |
|
manveru |
droundy: yes |
| 17:28 |
|
markstos |
droundy: Thanks. I just "sent" some doc-patches for the pre-req section. |
| 17:29 |
|
droundy |
markstos: I'm not sure when I'll have a chance to apply them... today I'm taking a break from darcs hacking. |
| 17:29 |
|
markstos |
droundy: I've always appreciated your life/hack balance. |
| 17:30 |
|
markstos |
http://bugs.darcs.net/ reports only 60 issues that need short-term attention now. That's encouraging. |
| 17:30 |
|
manveru |
droundy: http://p.ramaze.net/552 |
| 17:30 |
|
markstos |
Although there are plenty of deferred and wishlist items waiting to be put on a TODO list for Darcs 3. :) |
| 17:53 |
|
droundy |
manveru: it's definitely not making the transfer-mode connection, not sure why... I should add more debug output when the connection fails... |
| 17:53 |
|
droundy |
:( |
| 19:31 |
|
lispy |
markstos: how did you and kowey became certain that bytestring caused the bus error? |
| 19:42 |
|
markstos |
lispy: in the ticket, kowey said that when he tried again with bytestring disabled, the problem went away. |
| 19:43 |
|
lispy |
Oh, I didn't see that part of his email |
| 19:44 |
|
lispy |
is investigating the problem he had with the Hopefully patch |
| 19:45 |
|
markstos |
Great. Thanks lispy. |
| 19:46 |
|
markstos |
Shell question: In darcs test scripts we tend to use "set -ev". However, in this test script, it is correct for a particular command to fail. how do I handle that so overall test script still continues? |
| 19:47 |
|
lispy |
I'm not sure, I'm a perpetual newbie with sh |
| 19:47 |
|
lispy |
you could turn off set -ev, run the command, check $?, and then turn it back on? |
| 19:48 |
|
markstos |
hmm.. possibly. |
| 19:48 |
|
lispy |
there is likely a general solution though |
| 19:57 |
|
scode |
Anyone using darcs on freebsd/amd64? If so, how did you bootstrap ghc? |
| 19:57 |
|
scode |
I am tring to find a lazy man's way out to get ghc running on said platform ;) |
| 19:58 |
|
scode |
Hopefully doing something about lang/ghc in ports. |
| 19:58 |
|
markstos |
scode: There weren't binary packages for you? |
| 19:59 |
|
scode |
No official upstream for freebsd/amd64, and the port has no magic of its own as of now. Trying to figure out whether I am going to have to do it from scratch, but figured *someone* probably has it running already. |
| 20:00 |
|
markstos |
I would try the #haskell channel. |
| 20:00 |
|
scode |
Sounds like an idea. Dunno why I didn't think of that. :) Thanks. |
| 20:00 |
|
scode |
WIll do so later on; about to leave. |
| 20:03 |
|
lispy |
scode: you could also ask in #ghc potentially. That's probably a decent way to let them know that platform is in demand. |
| 20:04 |
|
scode |
Well, not trying to make someone go to lengths for it. But if someone has done the work I'd prefer to re-use it. Especially since I figure that the lack of a fix already indicates there might be something non-trivial about it. |
| 20:04 |
|
lispy |
I'm sure if they don't want to work on it, they'll say so :) |
| 20:05 |
|
lispy |
(or, the more polite way of phrasing that, "It can't hurt to ask") :) |
| 20:05 |
|
scode |
:) |
| 20:05 |
|
scode |
Will see what they say when I'm back or tomorrow. |
| 20:05 |
|
lispy |
sure |
| 20:05 |
|
lispy |
good luck |
| 20:07 |
|
markstos |
This bug report indicates the port is still in progress: http://hackage.haskell.org/trac/ghc/ticket/838 |
| 20:07 |
|
scode |
Yeah I found that, but hasn't been updated in a while. |
| 20:07 |
|
scode |
Will see. |
| 20:07 |
|
sm |
notes: darcs support in ikiwiki: http://ikiwiki.info/rcs/details/#index3h2 . darcs support in ohloh: http://www.ohloh.net/forums/3491/topics/1138 |
