[darcs-users] My darcs wish list

[Jason Dagit]

On Dec 22, 2005, at 4:49 AM, Albert Reiner wrote:

> Just a few comments:
>
> [Jason Dagit <dagit at eecs.oregonstate.edu>, Wed, 21 Dec 2005  
> 22:59:47 -0800]:
>> 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.
>
> My feeling is that this interactive scheme only works for simple
> situations, e.g., those where you only have to choose between two
> alternatives.  At any rate, by making the central repo accept a patch
> only if it applies cleanly and a test suite runs, it seems clear that
> you can set up a situation where nothing is to be done in the central
> repo but only in copies of it.

One of the things that happens to me with the current conflict  
handling is that I pull changes and then I'm told there are conflicts  
and I'm stuck with a messy file that can be hard to clean up.  Even  
if darcs only told me that there would be conflicts in file foo and  
gave me a chance to create a backup I'd be happier.  There is  
probably also a sequence of commands to restore the old version and  
the version that would have been pulled if no conflicts had happened,  
but I cannot think of it.

As for the other part of your comment, I've had problems where I had  
to do a pull and manually resolve conflicts from the "central repo".   
Perhaps I wasn't very careful and I should have done something  
differently, but it was unpleasant.

>
>> 2. Integration with more software. Here is an incomplete list of
>> software I've wanted darcs plugins for:
>
> But this does not seem to concern darcs proper but should be separate
> projects, I think.

Fair enough.  I don't mind if it is or is not part of darcs as long  
as someone does it :)

>
>> 6. A way to get automatic "unique" names for patches that you DO NOT
>> have to think about.
>
> I think you already have them, just that they are not displayed by
> default.  E.g., in one repo I have 119 patches called '[] [nw]'.  But
> I can easily get the unique name with --xml output:

Huh, cool.  I would have never thought to look at the xml output to  
find them.  The hashes are not exactly friendly names, but it's a start.

Thanks,
Jason