On Mon, Feb 20, 2006 at 02:40:50PM -0600, Matt Mackall wrote:
On Mon, Feb 20, 2006 at 09:09:30PM +0100, Radoslaw Szkodzinski wrote:
- Darcs' programming language is Haskell, which is compiled.
Mercurial is in Python - interpreted language as of yet.
Python is compiled - to portable byte
Travis Cross ha scritto:
All the same, I am still curious about the patch format. How is the
hash generated, and what is the middle value in the patch file name
(i.e. date-?-hash.gz)?
Here you can find the equivalent Python code that computes the hash:
[EMAIL PROTECTED] ha scritto:
The patch id isn't a hash of the patch, but a hash of the patch metadata. As
far as I know, this gains none of the benefits of hash-based identification but
suffers all of the costs and then some. Darcs probably would have done better
to choose a random 20-byte
Matt Mackall wrote:
Mercurial does no merging internally. But with the right tools
installed (merge and kdiff3, for example), the hgmerge script will
automatically merge non-conflicting changes.
Matt: Thanks for inventing Mercurial.
The deep difference between darcs and Mercurial is that
Purely from a use perspective, the implementation language should be of
no importance whatsoever.
Wrong: platform support is strongly influenced by the implementation
language.
-- O.L.
___
darcs-users mailing list
darcs-users@darcs.net
Hello to all,
FOSDEM was very interesting, with quite a few Darcs people being
around, especially much of the conflictors people. A pity that Ian
and Tommy couldn't come, I'd have liked to meet them.
What follows is a summary of my notes; please do correct me if I'm
incomplete or incorrect
Radoslaw Szkodzinski [EMAIL PROTECTED] writes:
Major differences [between Darcs and Mercury]:
You forget about the most important difference. Darcs has far better
support for cherry-picking than any other VC system, free or otherwise.
I recommend Darcs if you need cherry-picking. If you
As Benoit Boissinot mentioned : Mercurial uses binary diff to store the
files. I don't know how Darcs is doing.
Current Darcs versions are hopelessly inefficient with binary files.
I'd like to know more about their efficiency on binary files, for
lots of my documents are binary.
Then
Juliusz said that the lack of a Windows GUI for Darcs is a tragedy.
Somebody mentioned that the built-in GUI should work under Windows,
but Juliusz said that's not what he means by ``Windows GUI'', and that
Windows users like integration into the OS. Everyone sniggered.
Somebody said this
I'm seeing a marked performance difference between using a mapped
drive (remotely mounted via samba) and using ssh (to the same machine)
for my source darcs repositories.
This is more or less what I'd expect. SSH is an encrypted protocol,
and requires negotiating credentials on every
Eric Kow [EMAIL PROTECTED]:
I shall submit a patch removing all silliness from the date parser.
Which I'll reject. I enjoyed reading your code very much.
Juliusz
___
darcs-users mailing list
1. Use patches sent by mail, optionally with GPG-signing.
Is the patch itself signed or just the email?
The former. Signing of patches is being worked on, but it's a
difficult problem (due to certain properties of Darcs).
I don't get this thing about sending patches by email.
It's
James Bruce [EMAIL PROTECTED] writes:
Interestingly, this was from several months ago, and darcs get
doesn't notice any problem for some reason (maybe that's an issue
worth looking into).
No, it's normal. Darcs tries to makes local get as fast as possible,
so it simply copies files around.
When do I need --ask-deps?
Never.
Does this mean I have to use --ask-deps every time I use record to
make sure that when another user does a darcs pull everything gets
pulled?
No.
Juliusz
___
darcs-users
At present darcs will handle overlapping repos, and while
thrilling and abusable I lean more toward it being a bug than
a feature.
It's an accidental feature.
Juliusz
___
darcs-users mailing list
Any good suggestions, then, on how to approach handling the ordering
of patches without calling darcs every time?
Use repository ordering, but make sure that you regenerate your
database every time somebody calls an unsafe darcs operation.
Unsafe operations are optimize, repair, unpull and
this time, i was in the wrong directory and _darcs/ was missing.
admittedly the error messages weren't exactly clear about that,
The error message should be perfectly clear:
$ cd /tmp
$ darcs pull
darcs failed: Unable to darcs pull here.
You need to be in a repository directory to
Tough week. Here's what problem I tried to solve: If you and I
write one new patch type each without knowing each other, their
properties should be declared in some way so that darcs can
figure out how to commute them with each other.
You could simply declare that different user-defined patch
Thanks for the almost instantaneous reply. I didn't see it until
after Lele's reply because it ended up in the wrong folder (...no
darcs-users list headers, spam filtering...).
[EMAIL PROTECTED] wrote:
The patch id isn't a hash of the patch, but a hash of the patch
metadata. As far as I know,
Bryan O'Sullivan wrote:
The big drawback of darcs is that it has a theory of patches :-)
In
many practical cases, it simply falls on its face and takes seemingly
exponential time and space to try to figure out the
interrelationships
between patches. My impression is that there is no sign
In many practical cases, it simply falls on its face and takes
seemingly exponential time and space to try to figure out the
interrelationships between patches.
Interestingly no-one replied to this assertion. Do darcs developers feel
that the problem of poison patches etc is one that will be
On Mon, Feb 27, 2006 at 10:38:51PM +0100, Juliusz Chroboczek wrote:
Tough week. Here's what problem I tried to solve: If you and I
write one new patch type each without knowing each other, their
properties should be declared in some way so that darcs can
figure out how to commute them with
The patch id isn't a hash of the patch, but a hash of the patch
metadata. As far as I know, this gains none of the benefits of
hash-based identification but suffers all of the costs and then
some.
Interesting, and a bit peculiar ;) Though I suppose since the
datetime and the author
23 matches
Mail list logo
