Hello,
I wanted to give my wish list things that would make darcs work for
me in pretty much any situation I've needed it. If some of these
things have been fixed or added, I'd love to hear it :)
1. Conflicts should be handled more like recording. You know who the
conflict came from, you get a chance to deal with it or ignore it, it
can be interactive, and maybe copies should be made (a copy of each
version and the copy with war paint). As a sub point, I'm not
convinced that when using a "central darcs repo" that all conflicts
can be resolved without working in the central repo.
2. Integration with more software. Here is an incomplete list of
software I've wanted darcs plugins for:
* Visual Studio (Anhksvn might be a good project to modify)
* XCode on OSX (this may require reverse engineering)
* Tortoise-darcs (could we copy Tortoise svn/cvs?)
* GIMP undo history (I want to be able to branch in the undo
history and have dependencies computed for me)
3. Performance (much has been done, much is left to be done. Thanks
again to everyone that has worked on this.)
* darcs whats -l tends to be very, very slow, much slower than
you might expect
* binary files are slow (I think this is related patch format)
* commands which need to parse patches are slow due to patch format
* large patches are prohibitively slow. I'm talking multi-
megabyte patches
4. More introspection into what darcs has done. Basically, this is
logging of things such as, which patches were added in the last
apply. A start could be having darcs keep a log file of everything
it does to the repo. I think post hooks could be used to fake it,
but even then it would not be easy since currently nothing is passed
to the post hooks.
5. I can think of reasons to want binary deltas, but nothing really
compelling.
6. A way to get automatic "unique" names for patches that you DO NOT
have to think about. This is useful for when you need to have a
conversation with someone about a particular patch. Subversion does
with with it's global revision numbers and monotone uses sha1, if I
recall correctly. I've worked with people that would get lazy and
just name patches "stuff". After the 8th time my coworker did that
it was hard to talk about the patches they were submitting. I don't
see a reason why my friend can't submit a patch by that name, but it
would have been nice if it were "unique-ified" by darcs. I think
this would necessarily have to happen as the patch is created, which
makes it harder to do.
7. Partial checkouts or multi project repositories. With tools like
subversion you can checkout a subdirectory. This allows you to
manage a collection of related sources in one big repository. I
think this conflicts with darcs notion of the repository as a whole
entity, but sometimes it's really nice. Say I just want one file out
of a whole repo, it would be nice if I could checkout just as much as
I'm going to actually use.
8. More intelligent handling of protocol problems. I was using darcs
with a "server" that was really 4 servers on round robin dns and one
of the servers was alive but not accepting ssh/scp connections. When
you tried a push and won the flaky server lottery it would take
several minutes before you found out darcs was going to fail. Maybe
I just needed to use --verbose or something where darcs would say,
"Attempting connection.........." (printing dots very few seconds).
I just remember it being annoying because you'd sit there waiting
thinking that darcs was just being slow to process patches and then
you'd find out that darcs was unable to make one of the many
connections it needs to make. If I recall correctly, due to the dns
setup this could even happen after darcs had fetched the remote
history and interacted with the user about which patches to send.
9. I want more time to spend hacking on darcs. :-)
Proposed direction(s):
I'm going to try dedicating at least 6 hours/week to darcs as I would
really like to see it progress but I can't expect others to implement
the features I would want. I'm also forming the (weird) opinion that
the algorithms behind darcs should be factored out into a library,
say libdarcs, that has an exposed haskell and C API. Then darcs as
we know it would become the canonical use of libdarcs. Furthermore,
I want to do this is such a way that the storage of patches, history,
userperfs and so on can be whatever. My goal in this direction is to
experiment with using a database (sqlite in particular) as the
datastore for many of these things. I know that changing the patch
format could fix several of the problems I listed above, but I think
a database would make it easier to play with what is stored/cached
about the repository. I just have a hunch that a database would be
the least painful way to handle this.
Once we have the code factored out into libdarcs and darcs-frontend,
then I think it would be easy to construct guis and so on. I also
think that having a C API would help to attract non-haskell
programmers who just want to tweak darcs to work better with their
software. For example, I bet it would be much easier to mimic
Tortoise CVS using libdarcs than darcs-frontend. Or in a more
bizarre use, libdarcs could drive the undo/redo system in GIMP :)
Does these directions sound good to anyone else? I'm tempted to CC
David, but I don't want to slow down his progress on the GADTs.
Thanks,
Jason
_______________________________________________
darcs-users mailing list
[email protected]
http://www.abridgegame.org/mailman/listinfo/darcs-users
