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 <[EMAIL PROTECTED]> 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 _______________________________________________ darcs-users mailing list [email protected] http://www.abridgegame.org/mailman/listinfo/darcs-users
