git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Juliusz Chroboczek <Juliusz.Chroboczek@pps.jussieu.fr>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: darcs-devel@abridgegame.org, darcs-users@abridgegame.org,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: [darcs-users] Re: Git-aware Darcs: a tutorial
Date: Mon, 09 May 2005 21:41:39 +0200	[thread overview]
Message-ID: <7ihdhc426k.fsf@lanthane.pps.jussieu.fr> (raw)
In-Reply-To: <427FA400.2060408@zytor.com> (H. Peter Anvin's message of "Mon, 09 May 2005 10:55:12 -0700")

>> Darcs-git is a branch of Darcs that can work with Git repositories.

> How is it, performance-wise?

It depends very much on the command, but in general it's no faster
than plain Darcs right now, except for accessing the working
directory when you have an up-to-date cache.  The nice thing, of
course, is that since Darcs-git works on pure Git repositories, you
can always switch to using plain Git commands when an operation is
likely to be too slow, as I've done in the example above.

(Editor's note: ``Patch'' is Darcs-speak for what BK calls a Changeset.)

Commands that only touch the working dir and the top of the history --
darcs what, darcs record, and so on -- are relatively fast; unlike the
native Git equivalents, they stat every file in your tree (I'll be
fixing this RSN), but they don't touch the contents of unchanged
files.  Darcs whatsnew on a full kernel takes 4s on my machine.

Commands that read history (darcs changes, darcs send, darcs push) are
very fast until they encounter a merge, as they need to read the full
contents of one of the two branches (just the changed files, of
course).  In practice, that means that doing |darcs whatsnew| gets me
the last 90 patches in Linux' history in a few seconds, then stalls.
I've tried to track the problem down, but after an afternoon of work I
had gotten no further.  (I've explained the issue in excruciating
detail on Darcs-Devel, if you're interested.)

Commands that push patches around scale rather badly with the amount
of files touched by a patch.  In practice, this means that you'll be
able to push around all patches in a kernel tree in a reasonable time,
except for the initial commit (220MB of touched files), which you can
only push using the native Git tools.

And then there is what I consider as the actual showstopper: darcs diff
is completely brain-damaged (very much so in plain Darcs, even more so
in Darcs-git).  It needs a complete rewrite.

                                        Juliusz

      reply	other threads:[~2005-05-09 19:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-09 16:29 Git-aware Darcs: a tutorial Juliusz Chroboczek
2005-05-09 17:55 ` H. Peter Anvin
2005-05-09 19:41   ` Juliusz Chroboczek [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7ihdhc426k.fsf@lanthane.pps.jussieu.fr \
    --to=juliusz.chroboczek@pps.jussieu.fr \
    --cc=darcs-devel@abridgegame.org \
    --cc=darcs-users@abridgegame.org \
    --cc=git@vger.kernel.org \
    --cc=hpa@zytor.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).