[darcs-users] performance; clone?

[David Roundy]

On Tue, Apr 08, 2003 at 05:58:26PM -0700, Aaron Denney wrote:
> On Tue, Apr 08, 2003 at 08:20:05PM -0400, Dan Egnor wrote:
> > On Tue, Apr 08, 2003 at 04:34:30PM -0700, Aaron Denney wrote:
> > > > If you leave out the revert, it will have to try to resolve a large
> > > > number of conflicts in your working directory, which could take
> > > > some time.  > > > Right, I left out the revert.  A warning in the
> > > > documentation might be > > > in order.
> > 
> > There's a warning there now (maybe he just added it?).
> 
> I don't see it.  There's a warning that unrecord won't change your local
> copy, that you'll need to revert to do that.  But the implications aren't
> clear.

Hmmm.  I added a note about the possibility of an unpull.  Do you think
this is enough (you'll have to check it out in the darcs repo on
abridgegame, or on the docs at abridgegame.org), or should I add a bit more
explanation?

> > How hard would it be to, um, "unpull", which means to remove a patch and
> > also reverse its effects?
> 
> I would assume not that hard. 

Correct.  I've now added an unpull command.

> But if you're working in that area, I'd prefer the ability to unrecord a
> patch that isn't on the top.

Actually, that's already there (the FIXME in the documentation was
out-of-date).  It may have failed for you because of dependencies between
the patches.  I really should make unrecord check for dependencies _before_
prompting, or perhaps offer to also unrecord the patches which depend on
the patch you want to unrecord.

> Another feature requests: the ability to mark a patch as "I don't want
> it", which would be skipped in pulls, and help syncing between branches
> work better.

That's a good idea (and quite doable).  I've added it to the TODO, and may
get around to it in a couple of days or so.

> I should have a patch for zsh completion ready soon.

I got it (and applied it).

Thanks! Are zsh_completion_new and zsh_completion_old meant to be used with
new and old versions of zsh, or are they new and old versions of the
zsh_completion? Also, is there any standard place where these files would
get installed (e.g. bash_completion files can get stuck in
/etc/bash_completion.d/, at least on debian)? If so, perhaps you could
extend the make install to install the completion files?  I've also
realized that I probably should rename darcs_completion to
bash_completion...

(for others, Aaron sent me the patch using the 'darcs push' command, which
emails a patch)

For That was actually only the second time I've successfully used the
"darcs apply" command.  Once I got it working I stopped testing it (which
is part of why apply and push are marked experimental), because it was
getting tedious creating new patches to push and apply.  :) Obviously push
could use some serious polishing, as you ought to be able to edit text of
the email that gets sent, and I'd like to be able to gpg sign patches sent
with darcs push.  I just haven't figured out how best to do this.  Any
suggestions are definitely welcome.

I guess that's about all.  All the changes mentioned are in my repo on
abridgegame.org.

Oh yeah, and I don't think I mentioned that darcs get now checks if the
repo it's getting from is local.  If it's on the same filesystem, it
creates hard links to the patches, and I had to hack unrecord and unpull to
delete and recreate any patches they need to modify, when you unrecord a
patch that is not 'on the top', to make them compatible with the use of
hard links.  I also made a separate speedup for a local get (which after
the hard link took my darcs get from 2 min to 5 sec), which is to simply
copy the contents of the 'current' directory, rather than applying all the
patches.  For a remote pull over http, this isn't possible, because we
can't get directory listings.  Besides, when pulling over http we'd rather
minimize the downloading anyways, so once we have gotten all the patches,
we wouldn't want to download the files themselves.

There is still some work to be done on the hard link front, though, as pull
could check to see if you're pulling from a local repo, and if the patch
doesn't need any merging could create a hard link.

Testing of the hard link code would be appreciated (by creating repos on
the same partition and pulling back and forth between them, etc), as I'm
not likely to use it all that often, since my darcs repos of a given
project are all on different partitions.

btw, thanks again everyone for the suggestions! :)
-- 
David Roundy
http://www.abridgegame.org