| Time |
S |
Nick |
Message |
| 00:05 |
|
|
jonkri left #darcs |
| 00:16 |
|
|
kyagrd left #darcs |
| 00:51 |
|
|
owst joined #darcs |
| 00:57 |
|
|
mornfall left #darcs |
| 00:58 |
|
|
mornfall joined #darcs |
| 00:58 |
|
|
mornfall left #darcs |
| 00:58 |
|
|
mornfall joined #darcs |
| 01:08 |
|
|
gal_bolle left #darcs |
| 01:10 |
|
|
JaffaCake1 joined #darcs |
| 01:13 |
|
|
JaffaCake left #darcs |
| 01:36 |
|
|
sm_ joined #darcs |
| 01:38 |
|
|
sm__ joined #darcs |
| 01:39 |
|
|
gwern left #darcs |
| 01:39 |
|
|
sm left #darcs |
| 01:39 |
|
|
sm__ is now known as sm |
| 01:41 |
|
|
sm_ left #darcs |
| 01:56 |
|
|
gwern joined #darcs |
| 01:56 |
|
|
gwern left #darcs |
| 01:56 |
|
|
gwern joined #darcs |
| 02:27 |
|
|
gwern left #darcs |
| 02:36 |
|
|
gwern joined #darcs |
| 02:36 |
|
|
gwern left #darcs |
| 02:36 |
|
|
gwern joined #darcs |
| 02:42 |
|
|
gwern left #darcs |
| 02:50 |
|
|
dankna left #darcs |
| 03:00 |
|
|
gwern joined #darcs |
| 03:22 |
|
|
secorp joined #darcs |
| 04:38 |
|
|
gwern left #darcs |
| 04:41 |
|
|
gwern joined #darcs |
| 04:41 |
|
|
gwern left #darcs |
| 04:41 |
|
|
gwern joined #darcs |
| 04:54 |
|
|
gwern left #darcs |
| 05:01 |
|
|
gwern joined #darcs |
| 05:33 |
|
|
sm left #darcs |
| 05:44 |
|
|
jeltsch joined #darcs |
| 05:44 |
|
|
jeltsch left #darcs |
| 06:02 |
|
|
jderque joined #darcs |
| 06:04 |
|
|
Gwern-away joined #darcs |
| 06:04 |
|
|
Gwern-away left #darcs |
| 06:04 |
|
|
Gwern-away joined #darcs |
| 06:06 |
|
|
gwern left #darcs |
| 06:25 |
|
|
Gwern-away left #darcs |
| 06:30 |
|
|
gwern joined #darcs |
| 06:31 |
|
|
balor_ joined #darcs |
| 06:33 |
|
|
balor_ left #darcs |
| 06:33 |
|
|
balor_ joined #darcs |
| 06:37 |
|
|
kolmodin joined #darcs |
| 06:37 |
|
|
kolmodin left #darcs |
| 06:37 |
|
|
kolmodin joined #darcs |
| 07:40 |
|
|
Weltraumschaf joined #darcs |
| 07:54 |
|
|
balor_ left #darcs |
| 08:02 |
|
|
gwern left #darcs |
| 08:06 |
|
|
jderque left #darcs |
| 08:10 |
|
|
gwern joined #darcs |
| 08:14 |
|
|
JaffaCake1 is now known as JaffaCake |
| 08:21 |
|
|
raichoo joined #darcs |
| 08:22 |
|
|
gwern left #darcs |
| 08:36 |
|
|
gwern joined #darcs |
| 08:36 |
|
|
gwern left #darcs |
| 08:36 |
|
|
gwern joined #darcs |
| 08:36 |
|
plopix |
Heffalump: a shared repository is owned by group users and if a uses a 'darcs get' the gid is changed in primary gid of user |
| 08:36 |
|
|
kowey joined #darcs |
| 08:48 |
|
|
shenshei joined #darcs |
| 08:49 |
|
|
Gwern-away joined #darcs |
| 08:49 |
|
|
Gwern-away left #darcs |
| 08:49 |
|
|
Gwern-away joined #darcs |
| 08:52 |
|
|
gwern left #darcs |
| 08:55 |
|
lelit |
plopix: that's the usual behaviour, what did you expect instead? |
| 08:57 |
|
lelit |
I mean, when you "cp" a file owned by someone else (if you have read perms that is) the new file will have you/your-primary-group as owner |
| 08:57 |
|
mornfall |
You could (ab)use group sticky bits to work around that. |
| 08:58 |
|
lelit |
you mean when that is set on the container folder? |
| 08:58 |
|
mornfall |
Yep. |
| 09:11 |
|
Weltraumschaf |
hi, where can i find explanation of the new conflict markers with the ===. its not dewscribed here http://wiki.darcs.net/ConflictsFAQ |
| 09:17 |
|
kowey |
http://darcs.net/manual/Darcs_[…]11000000000000000 talks about them |
| 09:17 |
|
kowey |
it'd be fantastic if somebody could update the conflicts FAQ accordingly |
| 09:35 |
|
|
Gwern-away left #darcs |
| 09:55 |
|
|
gwern joined #darcs |
| 09:55 |
|
|
gwern left #darcs |
| 09:55 |
|
|
gwern joined #darcs |
| 10:04 |
|
|
jderque joined #darcs |
| 10:04 |
|
Weltraumschaf |
thx |
| 10:11 |
|
|
gwern left #darcs |
| 10:16 |
|
|
gwern joined #darcs |
| 10:16 |
|
|
gwern left #darcs |
| 10:16 |
|
|
gwern joined #darcs |
| 10:21 |
|
|
gwern left #darcs |
| 10:31 |
|
|
gwern joined #darcs |
| 10:31 |
|
|
gwern left #darcs |
| 10:31 |
|
|
gwern joined #darcs |
| 10:40 |
|
|
gwern left #darcs |
| 10:41 |
|
|
gwern joined #darcs |
| 10:41 |
|
|
gwern left #darcs |
| 10:41 |
|
|
gwern joined #darcs |
| 10:58 |
|
|
gwern left #darcs |
| 11:01 |
|
|
gwern joined #darcs |
| 11:01 |
|
|
gwern left #darcs |
| 11:01 |
|
|
gwern joined #darcs |
| 11:21 |
|
|
gwern left #darcs |
| 11:28 |
|
|
gwern joined #darcs |
| 11:43 |
|
|
gwern left #darcs |
| 11:48 |
|
|
gwern joined #darcs |
| 11:48 |
|
|
gwern left #darcs |
| 11:48 |
|
|
gwern joined #darcs |
| 11:58 |
|
|
gwern left #darcs |
| 11:59 |
|
|
raichoo left #darcs |
| 12:09 |
|
|
raichoo joined #darcs |
| 12:10 |
|
|
dankna joined #darcs |
| 12:14 |
|
|
gwern joined #darcs |
| 12:14 |
|
|
gwern left #darcs |
| 12:14 |
|
|
gwern joined #darcs |
| 13:02 |
|
|
gwern left #darcs |
| 13:06 |
|
|
jderque left #darcs |
| 13:14 |
|
|
gwern joined #darcs |
| 13:21 |
|
|
gwern left #darcs |
| 13:35 |
|
|
gwern joined #darcs |
| 13:35 |
|
|
gwern left #darcs |
| 13:35 |
|
|
gwern joined #darcs |
| 13:40 |
|
|
gwern left #darcs |
| 14:01 |
|
|
gwern joined #darcs |
| 14:04 |
|
|
gal_bolle joined #darcs |
| 14:08 |
|
|
raichoo left #darcs |
| 14:09 |
|
|
gwern left #darcs |
| 14:21 |
|
|
gwern joined #darcs |
| 14:21 |
|
|
gwern left #darcs |
| 14:21 |
|
|
gwern joined #darcs |
| 14:51 |
|
|
sm joined #darcs |
| 15:02 |
|
|
Gwern-away joined #darcs |
| 15:02 |
|
|
Gwern-away left #darcs |
| 15:02 |
|
|
Gwern-away joined #darcs |
| 15:05 |
|
|
secorp left #darcs |
| 15:05 |
|
|
gwern left #darcs |
| 15:08 |
|
|
Gwern-away is now known as gwern |
| 15:08 |
|
|
etarasov joined #darcs |
| 15:11 |
|
dixie |
hehe |
| 15:11 |
|
dixie |
http://qubodup.soup.io/post/12[…]rcurial-vs-Bazaar |
| 15:12 |
|
|
shenshei left #darcs |
| 15:12 |
|
|
balor joined #darcs |
| 15:12 |
|
kowey |
that's including plugins, I suppose |
| 15:13 |
|
kowey |
oh, nevermind, misread |
| 15:14 |
|
owst |
So he's looking for Arch packages that pull from a repo to build the latest package... as he says, not sure what you can learn from it. |
| 15:16 |
|
Phlogistique |
"the underground Bazaar" |
| 15:31 |
|
|
balor left #darcs |
| 15:31 |
|
|
balor joined #darcs |
| 15:42 |
|
|
raichoo joined #darcs |
| 15:43 |
|
|
raichoo left #darcs |
| 15:43 |
|
|
zooko joined #darcs |
| 15:43 |
|
zooko |
Hello, people of #darcs! |
| 15:43 |
|
zooko |
I'm having this trouble again, which I've reported before and someone explained that it couldn't possibly be doing that or I must be confused. |
| 15:44 |
|
zooko |
The trouble is, davidsarah has posted a patch on our trac: |
| 15:44 |
|
zooko |
http://tahoe-lafs.org/trac/tah[…]et/1404#comment:2 |
| 15:44 |
|
zooko |
And when I run darcs apply on it, darcs says: |
| 15:44 |
|
zooko |
darcs: Cannot apply this patch bundle, since we're missing: |
| 15:44 |
|
zooko |
Sun Jan 30 09:49:23 MST 2011 david-sarah jacaranda.org |
| 15:44 |
|
zooko |
* scripts/common.py: don't assume that the default alias is always 'tahoe' (it is, but the API of get_alias doesn't say so). refs #1342 |
| 15:44 |
|
zooko |
|
| 15:45 |
|
zooko |
But, I really doubt that davidsarah's patch "docs: remove out-of-date docs/testgrid/introducer.furl and containing directory. fixes #1404", which I'm trying to apply, actually depends on "scripts/common.py: don't assume that the default alias is always 'tahoe' (it is, but the API of get_alias doesn't say so). refs #1342" |
| 15:45 |
|
zooko |
I'm sure it doesn't, because it doesn't even ... |
| 15:45 |
|
* zooko |
double checks |
| 15:48 |
|
zooko |
So the new one that I'm trying to apply has hunk ./docs/testgrid/introducer.furl, rmfile ./docs/testgrid/introducer.furl and rmdir ./docs/testgrid. |
| 15:48 |
|
zooko |
The old one that it is saying it is missing has hunk scripts/common.py |
| 15:48 |
|
zooko |
So there's no way that one depends on that other one. |
| 15:48 |
|
|
gal_bolle left #darcs |
| 15:51 |
|
kowey |
hi zooko: it's not really a question of dependencies |
| 15:51 |
|
|
shenshei joined #darcs |
| 15:52 |
|
zooko |
Hi kowey. |
| 15:52 |
|
kowey |
darcs send on davidsarah's side just pessimistically assumes whatever context the remote repo has at the time of send |
| 15:53 |
|
kowey |
it does not make any effort to produce what is called a "minimal" context, ie. by commuting the patch down to actually the minimum number of dependencies it needs |
| 15:53 |
|
zooko |
So, that's what I thought, which is why I added these instructions for our contributors to work around this: |
| 15:53 |
|
zooko |
http://tahoe-lafs.org/trac/tah[…]21&old_version=20 |
| 15:54 |
|
zooko |
But then I couldn't reproduce it and then someone -- lispy? -- on this channel told me I was wrong and this was all unnecessary |
| 15:54 |
|
zooko |
So I undid the workaround instructions: http://tahoe-lafs.org/trac/tah[…]23&old_version=22 |
| 15:54 |
|
zooko |
But apparently I was right and I need to re-establish the workaround? |
| 15:54 |
|
kowey |
forgive me for asking (this is a bit of a "have you tried turning it off and on"), but are you sure the repo you are applying the patch to is up to date? |
| 15:55 |
|
zooko |
It is not up to date. |
| 15:55 |
|
zooko |
I didn't intend for it to be up to date. |
| 15:56 |
|
kowey |
when you say it's not up to date, you mean it contains fewer patches than http://tahoe-lafs.org/source/tahoe-lafs/trunk pristine ? |
| 15:56 |
|
zooko |
Yes. |
| 15:57 |
|
kowey |
ah, I notice their patch was for davidsarahdev.allmydata.org:/home/darcs/tahoe/trunk |
| 15:58 |
|
zooko |
Yes. |
| 15:58 |
|
kowey |
so basically, if davidsarah normally just push/pull against that repo |
| 15:58 |
|
zooko |
So, I feel like I must be missing something conceptually here. Isn't the ability to apply only a subset of the patches, i.e. the ones that the desired patch depends on, kind of the core thing that differentiates darcs from the rest? |
| 15:58 |
|
zooko |
Why does this core thing not work with "darcs apply" when it works with "darcs pull"? |
| 15:59 |
|
kowey |
well hang on, let's get to things one step at a time |
| 15:59 |
|
kowey |
are you confident now that the issue is just a limitation, and not an actual bug? |
| 15:59 |
|
kowey |
or should we establish the forensics behind that fact first? |
| 16:00 |
|
zooko |
Yes, I understand that. |
| 16:01 |
|
zooko |
Last time around I was confused about the difference between the "extra" patches being in davidsarah's repo from which they are running "darcs send" vs. the "extra" patches being in the repo to which they are targetting the darcs send. |
| 16:01 |
|
zooko |
There are 3 repos involved here, compared with only 2 repos for push or pull. |
| 16:01 |
|
kowey |
OK thanks |
| 16:01 |
|
zooko |
So the workaround instructions I wrote were incorrect, as they were saying that you needed to avoid extraneous patches in your -- source -- repo when doing "darcs send". |
| 16:02 |
|
kowey |
hmm |
| 16:03 |
|
kowey |
well, before trying to think about what the correct instructions are, let's think a bit more about what we should expect darcs to do |
| 16:03 |
|
kowey |
(sorry, this is just a UI curiosity for me -- ie. what would users of darcs send and apply expect?) |
| 16:03 |
|
zooko |
I guess the correct workaround for our workflow is for the person doing the applying: instead of just running "cd $MYREPO && darcs apply $PATCH", you should do "darcs get --lazy $TRUNK pristine && cd pristine && darcs apply $PATCH && cd ../$MYREPO && darcs pull --patch="$PATTERN" ../pristine && cd .. && /bin/rm -rf ./pristine". |
| 16:03 |
|
zooko |
:-) |
| 16:03 |
|
kowey |
one workflow which may work for you is |
| 16:04 |
|
kowey |
darcs get http://mainrepo --context foo.dpatch |
| 16:04 |
|
kowey |
cd mainrepo |
| 16:04 |
|
zooko |
What's --context mean? |
| 16:04 |
|
kowey |
darcs apply ../foo.dpatch -i |
| 16:05 |
|
kowey |
when given a context file (a dpatch file happens to double as a context file), darcs get --context will grab the repo and unapply all the patches that are not listed in that bottom part of the patch bundle |
| 16:05 |
|
kowey |
OK, the --context is superfluous come to think of it :-) |
| 16:06 |
|
kowey |
but darcs get --context will basically make the repo you're getting look like the intersection of davidsarah's repo and the repo they were sending to at the time of the send |
| 16:06 |
|
zooko |
Ok. |
| 16:06 |
|
zooko |
Cool. |
| 16:06 |
|
kowey |
(which can be handy for looking at line numbers, and also getting a better sense of what the original author intended) |
| 16:07 |
|
kowey |
(particularly when you're trying to untangle a conflict -- this lets you get an "X thinks 'foo'" and "Y thinks 'bar'" understanding) |
| 16:08 |
|
kowey |
I think your workflow looks right, I'm not completely sure |
| 16:08 |
|
zooko |
Okay thanks, I think I understand the issue now. |
| 16:08 |
|
kowey |
we have a similar issue with our screened/reviewed distinction |
| 16:09 |
|
kowey |
and I have some scripts that manage the bureaucracy a bit |
| 16:09 |
|
zooko |
I still don't know why the logic that chooses to pull only a subset of patches from a repo can't also choose to apply only a subset of patches when running "darcs apply $PATCHFILE", and then stop and complain *only* when it needs a patch and that patch isn't available. |
| 16:10 |
|
|
jderque joined #darcs |
| 16:10 |
|
zooko |
For example, in that work-around work-flow that you and I just sketched out |
| 16:10 |
|
zooko |
At the end of it, you run "darcs pull --patch="$PATTERN" ../mainrepo" |
| 16:10 |
|
zooko |
And darcs pulls *only* $PATTERN plus any required dependencies -- it doesn't pull all patches from ../mainrepo. |
| 16:10 |
|
zooko |
So why can't it do the same thing if I just say "darcs apply $PATCHFILE"? |
| 16:11 |
|
kowey |
I think you can use darcs apply -p btw |
| 16:11 |
|
kowey |
but that's not really answering your question |
| 16:12 |
|
kowey |
one way to look at the situation, is that darcs pull and darcs apply are (like in your model) doing the same thing, right? grabbing some patches from a repository (in the pull case), or a virtual repository (ie. a bundle) in the apply case |
| 16:13 |
|
zooko |
Okay, I suppose so. |
| 16:13 |
|
kowey |
and in that way of looking at it, nobody ever got around to writing an extra bit of code that makes it such that when you try to "pull" patches from a bundle |
| 16:13 |
|
kowey |
and those patches are not literally in the bundle |
| 16:13 |
|
kowey |
that it should some smart virtual repository magic by fetching said patches from elsewhere |
| 16:14 |
|
kowey |
so that's one way to understand the situation |
| 16:14 |
|
zooko |
No, that's not what I'm asking for. |
| 16:14 |
|
zooko |
All I'm asking for is that it does not stop because of the fact that the bundle mentions a patch that I don't have but also don't need. |
| 16:14 |
|
zooko |
So in this case there is only one patch in the bundle. |
| 16:15 |
|
kowey |
how do you know you don't need the patch in question? |
| 16:15 |
|
zooko |
Plus, it *mentions* all the patches that were in the central repo at the time of "darcs send". |
| 16:15 |
|
zooko |
By the same way that you know you don't need it when you do "darcs pull" in our work-around work-flow. |
| 16:15 |
|
kowey |
OK, so that's the interesting missing bit of mental model I should fill in |
| 16:15 |
|
kowey |
(thank-you, this is very educational for me, but I may not remember the lessons at a useful point) |
| 16:16 |
|
kowey |
the missing bit of mental model |
| 16:16 |
|
kowey |
is that the mechanism for darcs to determine if it needs the patch in question requires it to actually have the patch in question |
| 16:16 |
|
kowey |
so when you do a darcs pull, and it does all its cherry picking magic |
| 16:16 |
|
kowey |
it actually fetches the patches you're trying to cherry pick past so that it can calculate its commutations |
| 16:17 |
|
kowey |
do you agree that this patch fetching was missing from your mental model? |
| 16:17 |
|
zooko |
Yes. |
| 16:17 |
|
kowey |
basically it has to actually look at the patch first to know it doesn't need it |
| 16:18 |
|
zooko |
sigh |
| 16:18 |
|
kowey |
so in the case of darcs pull, fetching the patch is straightforward, just grab it |
| 16:18 |
|
kowey |
in the case of darcs apply, well all we have is the name of the patch |
| 16:18 |
|
kowey |
a *smarter* darcs might somehow try to grab the patch from a third party |
| 16:18 |
|
kowey |
unfortunately, the current darcs isn't that smart |
| 16:19 |
|
kowey |
(and also it's not clear if such smartness would end up biting us in the long run) |
| 16:19 |
|
zooko |
Also that would open up other failure modes. |
| 16:19 |
|
zooko |
Yeah what you said. |
| 16:19 |
|
kowey |
sorry, this is one of the downsides of our whole-history approach |
| 16:20 |
|
kowey |
ie. when we mean whole history, we're actually talking about the patch contents too |
| 16:20 |
|
kowey |
:-( |
| 16:22 |
|
zooko |
I still think there is an opportunity for optimization here. |
| 16:22 |
|
zooko |
If I have a repo with patches P1..PN in it. |
| 16:22 |
|
zooko |
And then I add PN+1 to that repo. |
| 16:22 |
|
zooko |
And then I add PN+2 to that repo. |
| 16:22 |
|
zooko |
Then it can never be the case that PN+1 depends on PN+2. |
| 16:22 |
|
kowey |
I'm afraid I have to run, but hopefully the rest of #darcs can comment |
| 16:22 |
|
zooko |
No matter what commutations PN+1 or PN+2 go through. |
| 16:23 |
|
zooko |
Thanks for the help! |
| 16:23 |
|
kowey |
thanks for improving darcs :-) |
| 16:23 |
|
|
kowey left #darcs |
| 16:56 |
|
|
owst left #darcs |
| 17:04 |
|
|
zooko left #darcs |
| 17:10 |
|
|
zooko joined #darcs |
| 17:16 |
|
Heffalump |
zooko: so if a rpo contains P1...PN; PN+1; PN+2 and you send PN+1 only, you get a context with PN+2 in it? |
| 17:17 |
|
Heffalump |
if so, that's fixable without a lot of work (I think) so worth a bug specifically about that. |
| 17:17 |
|
zooko |
Heffalump: my current understanding is that if you send *to* a repo with Q1..QN from a repo with P1..PN; PN+1; PN+2 and you send PN+1 then it makes a context with Q1..QN in . |
| 17:17 |
|
zooko |
Maybe my understanding is still somewhat wrong though. |
| 17:18 |
|
Heffalump |
I would have expected it to use intersection(P1..PN,Q1..QN) |
| 17:18 |
|
Heffalump |
mine might be wrong too, I'm just thiking about the underlying mechanics |
| 17:21 |
|
dixie |
oh maybe I just get the point of the discussion, so when I do "darcs send" to some remote/public repo the context of dpatch should not include dependencies on patches not in target repo (and not part of the dpatch being sent). |
| 17:22 |
|
dixie |
hmm :-) not very good english. |
| 17:23 |
|
dixie |
when "darcs send" want to declare dependency on some patch not in "public target repo" it should include it in dpatch. |
| 17:34 |
|
zooko |
dixie: I am still somewhat uncertain of my understanding, but I think darcs currently does what you should said correctly. |
| 17:34 |
|
zooko |
The problem I'm having is different. There are three repos: A, B, and C. A person does a darcs send from A to B, then a different person applies the resulting patch to C. |
| 17:35 |
|
zooko |
My problem is: C sometimes doesn't have all the patches from B. |
| 17:35 |
|
zooko |
The workaround is: the second person, the applier, has to maintain a mirror of B, apply the patch to that mirror, then use "darcs pull" to move just the patch (plus any deps) to C. |
| 17:43 |
|
Heffalump |
is C actually available to the person doing the send from A? |
| 17:44 |
|
Heffalump |
the general problem is that it's computationally expensive to send against a minimal context, and if we can't see C, then the only remaining middle ground is some kind of heuristic guess at what to send against. |
| 17:44 |
|
|
secorp joined #darcs |
| 17:47 |
|
|
balor left #darcs |
| 17:48 |
|
zooko |
Heffalump: I still think there is a possibility for improvement without guessing, by recording the set of patches that a given patch *might* depend on. |
| 17:49 |
|
zooko |
That set can only monotonically shrink on closer inspection, right? |
| 17:49 |
|
zooko |
So an initial, cheap-to-compute answer is "all patches in the repo where it was recorded'. |
| 17:50 |
|
|
Weltraumschaf left #darcs |
| 17:50 |
|
Heffalump |
remember we're takling about a given patch *representation*. |
| 17:51 |
|
Heffalump |
And the set of things that can depend on (in the sense of X depends on Y if you need Y to be able to apply X) changes when you pull X into another repo. |
| 17:51 |
|
Heffalump |
this sense of dependency is different from the normal darcs sense where a patch depends on another patch if you can't commute them; that is invariant. |
| 17:55 |
|
zooko |
Ah. |
| 17:55 |
|
zooko |
That sounds wrong that this sense of dependency can increase. |
| 17:55 |
|
Heffalump |
why? |
| 17:55 |
|
zooko |
I.e. there is a patch P which doesn't depend on Q, and when you pull some more patches into the repo the P does depend on Q. That shouldn't happen. |
| 17:56 |
|
zooko |
Or, there is a patch P in a repo, and then you pull patch Q into the repo and now P depends on Q. That shouldn't happen. |
| 17:56 |
|
zooko |
Is that what you mean? |
| 17:56 |
|
zooko |
Sorry, gotta run... |
| 17:56 |
|
Heffalump |
remember it's just the representation |
| 17:56 |
|
Heffalump |
but it doesn't happen that way round, it only happens if you pull P into a nother repo, or if you do a reorder in the original repo |
| 17:58 |
|
|
balor joined #darcs |
| 18:03 |
|
Heffalump |
in any repo, the representation of a patch can only depend on the representation of the patches before it. |
| 18:03 |
|
Heffalump |
and operations in a single repo always add new patches at the end, apart from optimize --reorder. |
| 18:08 |
|
|
exlevan left #darcs |
| 18:09 |
|
|
exlevan joined #darcs |
| 18:13 |
|
|
gwern left #darcs |
| 18:15 |
|
|
gwern joined #darcs |
| 18:15 |
|
|
gwern left #darcs |
| 18:15 |
|
|
gwern joined #darcs |
| 18:22 |
|
|
lelit` joined #darcs |
| 18:37 |
|
|
lelit` left #darcs |
| 18:40 |
|
|
owst joined #darcs |
| 18:50 |
|
|
secorp left #darcs |
| 19:11 |
|
Heffalump |
|
| 19:11 |
|
Heffalump |
sorry |
| 19:32 |
|
|
owst left #darcs |
| 19:56 |
|
|
Modius joined #darcs |
| 20:17 |
|
|
owst joined #darcs |
| 20:19 |
|
|
gal_bolle joined #darcs |
| 20:28 |
|
|
kowey joined #darcs |
| 20:31 |
|
|
gal_bolle left #darcs |
| 20:34 |
|
|
dankna left #darcs |
| 20:35 |
|
zooko |
lelit: I just got this error message from my trac: Warning: HTML preview using PygmentsRenderer failed (IntegrityError: columns repo_id, node_id, rev, up_to_line are not unique) |
| 20:35 |
|
zooko |
Reloading, it went away and I got proper syntax highlighting. |
| 20:36 |
|
|
dankna joined #darcs |
| 20:41 |
|
|
raichoo joined #darcs |
| 20:41 |
|
|
jderque left #darcs |
| 21:06 |
|
|
zooko left #darcs |
| 21:22 |
|
Modius |
What's the darcs/camp relationship - is Camp = darcs 3? |
| 21:23 |
|
Heffalump |
no formal relationship |
| 21:24 |
|
Modius |
That youtube vid (http://projects.haskell.org/camp/unique ) - does that basically describe darcs functionality as well? |
| 21:24 |
|
Heffalump |
yes |
| 21:25 |
|
Heffalump |
camp is a personal project of Igloo, who spent a lot of time working on darcs in the past. At the moment his main focus is making a formal proof of correctness of what camp does. |
| 21:26 |
|
Heffalump |
we don't really know what the long-term outcome will be. In theory it could become darcs 3, though I think it's more likely that darcs will learn lessons from camp rather than becoming camp. |
| 21:26 |
|
Modius |
I don't know much about proofs - does this have anything to do with what the DVCS actually *does*? Or is it just a theoretical exercise? |
| 21:27 |
|
Heffalump |
it's proving that what it does has the properties we expect, so yes it does have something to do with it |
| 21:28 |
|
Modius |
History/popularity have been dragging me toward git; but I find darcs intriguing (the camp video made a good summary) |
| 21:29 |
|
Modius |
It's something that's been eating at me - that changes in one view aren't history, they're just changes. |
| 21:30 |
|
Heffalump |
it's generally considered by people who have used both to have a much nicer UI, and the patch handling is (we claim!) very natural. On the other hand it does have some performance and reliability problems, and a much smaller ecosystem. |
| 21:32 |
|
|
alexsuraci left #darcs |
| 21:34 |
|
Modius |
And the core primitive is the patch, right? No "branches" (or what we'd call big branches are separate repos, right?) |
| 21:38 |
|
Heffalump |
correct |
| 21:50 |
|
|
alexsuraci joined #darcs |
| 21:51 |
|
|
kowey left #darcs |
| 22:23 |
|
|
raichoo left #darcs |
| 22:29 |
|
|
alexsuraci left #darcs |
| 22:33 |
|
|
alexsuraci joined #darcs |
| 22:40 |
|
|
dankna left #darcs |
| 22:40 |
|
|
exlevan left #darcs |
| 22:40 |
|
|
ocharles left #darcs |
| 22:44 |
|
|
dankna joined #darcs |
| 22:44 |
|
|
exlevan joined #darcs |
| 22:44 |
|
|
ocharles joined #darcs |
| 23:28 |
|
|
etarasov left #darcs |
| 23:29 |
|
|
etarasov joined #darcs |
| 23:36 |
|
|
etarasov left #darcs |
| 23:37 |
|
|
etarasov joined #darcs |
