[darcs-users] Re: Where Arch is going

David Roundy droundy at darcs.net
Fri Jun 3 12:56:23 UTC 2005


On Wed, Jun 01, 2005 at 12:51:07PM -0500, John Goerzen wrote:
> On Wed, Jun 01, 2005 at 07:23:12PM +0200, Erik Bågfors wrote:
> > On 6/1/05, John Goerzen <jgoerzen at complete.org> wrote:
> > > Incidentally, this bazaar-ng tutorial seems strikingly similar to darcs
> > > in some areas, right down to bzr send...
> > > 
> > > http://www.bazaar-ng.org/tutorial.html
> > 
> > Of course, the whole idea of bazaar-ng is to take the best features
> > from darcs, arch, svn, etc and make something even better.  Darcs has
> > some really great things when it comes to easy to use and
> > collaboration over emails etc. Stupid not to use those ideas.
> 
> Right.  But the reason I'm posting here is to get a feel for where darcs
> is headed down the road.
> 
> Let's say that bazaar-ng is successful and implements all that is good
> about darcs.  That would mean there is really no need for darcs any
> longer.  I, for one, wouldn't mind a VC system that has all of darcs'
> features without its performance problems.  Why would people choose
> darcs in that situation?

I'd say that there are three things that are good about darcs: its simple
distributed workflow (i.e. every working directory is a repository), its
interface (e.g. darcs record allowing you to select changes from within a
file) and its support for cherry-picking (and by extention, amend-record,
unrecord, unpull, etc).  The first two can pretty easily be added to other
SCMs, and quite likely will be added soon.  The third however, will take
more time.

The problem that noone has really solved (although I think darcs comes the
closest, and will have solved if I can get the conflictor stuff solidly
working) is how to support cherry-picking in a distributed environment.
I'd almost say that noone else has really addressed the question.

With distributed cherry-picking, many of darcs' more unique features that
allow you to revise your history (such as unpull, unrecord, amend-record)
come automatically, since if they weren't implemented in the tool, you
could acheive the same results using a cherry-picking pull.

The catch is that in order to avoid either corruption or user-interface
nightmares, you need to make sure that pulling patches out-of-order doesn't
give different results from pulling them in-order.  This is why darcs has
all its merge conflict troubles, and it's the issue that (to my knowledge)
hasn't been addressed by any other SCM.  Without solving this problem, you
can't have *real* distributed cherry-picking.

Arch (as well as its derivatives) supports cherry-picking, but as you point
out elsewhere, you aren't really moving the patches from one branch to
another, just the associated logs, and a new log is generated each time you
do so--introducing user-visible complexity, and making the merge history
visible (and yet without remembering the history itself).

> What features can darcs pull in from other VCs?  What is the vision for
> where darcs will be in a year or two?
>
> Most of what I've heard about that question involves not spinning with
> merges and implementing git, but no talk about anything exciting.

The reason is that the conflicts issue is a serious one.  There are bugs in
the current implementation that are extremely serious.  Until we've got a
robustly working conflict mechanism (the existing one works, but isn't
robust), that's what I need to focus on.

Interfacing with git is an interesting problem because it's a model for
interfacing with any other distributed SCM, but git is sufficiently simple
that it's not too hard.

I think your question is where darcs will be going once the conflictor code
is complete and well-tested? The long-time TODO list includes addition of
new patch types that will reduce the danger of conflicts in certain
situations (e.g. paragraphs wrapped at 72 lines--of course 72 wouldn't be
hard-coded).  This would be great for the papers I work on, which are of
course written in latex... we'd be able to simultaneously edit the same
paragraph perhaps.  Also an indentation patch type would be nice, again to
reduce the incidence of conflicts.  And hunk moves (and possibly inter-file
hunk moves).

On the more mundane side, support for signed repositories is only waiting
on an implementor.

And if I had a infinite number of monkeys banging on keyboards, I'd assign
some fraction of them (which fortunately would also be an infinite number)
to work on a gui or ncurses interface for patch selection--it would really
be much better than the current interface.  Another interesting problem
would be that of creating a sort of lexing/parsing language that would
allow customized patch types that are specific to a particular programming
language.  This is a particularly hard problem, as you'd need to have the
parsing always succeed and always give meaningful (and reasonable) results.
And the resulting patches would have to merge and commute in a meaningful
and useful manner.
-- 
David Roundy
http://www.darcs.net




More information about the darcs-users mailing list