Dear Darcs hackers

Here's an authentic user experience that I thought you might want to
consider.

I came back to a Darcs tree that I have on a random machine.  I typed
'darcs pull -av'. That takes long enough that I did something else.
Before I knew it I was sucked into something else, and it was not until
the next day that I cam back to my tree.

So I did another pull, just to be sure.  Then I thought I'd see what
changes I had in my tree.  I type 'darcs what -s'.  Oh lord!  Lots of
changes. 

I look. No, they aren't my changes.  In fact, they are *undoing* patches
done by others. If I record and commit these changes, they'll undo
others' work.

So I should use 'darcs revert'.  But alas!  There *were* a few changes
of my own in my tree, but they are now utterly buried in a morass of
other glop.  So I manually went file by file, trying to figure out which
changes were mine (from my earlier work in this tree), and which were
someone else's (somehow dumped into my tree by Darcs as negative
patches).

I honestly can't explain how these negative changes ended up in my tree.
Maybe it's something like the earlier discussion we had about what
happens when Darcs quits part-way.  (issue255 I think)

But regardless, 

	is it not very bad to dump arbitrary amounts 
	of goop into my precious working directory?

It certainly caused me a lot of work on this occasion, which (even if
the user is stupid, which is likely) must count as a negative user
experience.  Is there some what I can avoid this in future?

Simon

On Fri, Sep 29, 2006 at 12:46:51 +0000, simonpj wrote:
> It certainly caused me a lot of work on this occasion, which (even if
> the user is stupid, which is likely) must count as a negative user
> experience.  Is there some what I can avoid this in future?

When doing pulls in these situation, I sometimes record a patch "DRAFT
DRAFT DRAFT (do not send)", pull, unrecord, repair conflicts and
re-record at my leisure.  Would it help in this case?

When we were discussing the ignore/unignore file feature on darcs-users,
I think some discussion about a potential "local patch" feature came up.
Perhaps that could make this kind of thing easier to deal with.

On Fri, Sep 29, 2006 at 12:46:50PM +0000, simonpj wrote:
> 
> Is there some what I can avoid this in future?

It's generally considered a good idea to "darcs record --all" before
pulling if you're not sure there won't be any conflicts or anything.

Perhaps darcs should do this itself on pull, but put the patch somewhere
other than in the repository patch sequence?

Thanks
Ian

On Mon, Oct 02, 2006 at 04:26:03PM +0000, Ian Lynagh wrote:
> It's generally considered a good idea to "darcs record --all" before
> pulling if you're not sure there won't be any conflicts or anything.
> 
> Perhaps darcs should do this itself on pull, but put the patch somewhere
> other than in the repository patch sequence?

Yeah, that's not a bad idea.  We could perhaps optionally do this, and
store it as a patch bundle that could be applied with apply.  Or by default
do it, but allow the action to be optionally overrided.
-- 
David Roundy
http://www.darcs.net

> David Roundy <droundy@darcs.net> added the comment:
> On Mon, Oct 02, 2006 at 04:26:03PM +0000, Ian Lynagh wrote:
> > It's generally considered a good idea to "darcs record --all" before
> > pulling if you're not sure there won't be any conflicts or anything.
> > 
> > Perhaps darcs should do this itself on pull, but put the patch somewhere
> > other than in the repository patch sequence?
> 
> Yeah, that's not a bad idea.  We could perhaps optionally do this, and
> store it as a patch bundle that could be applied with apply.  Or by default
> do it, but allow the action to be optionally overrided.

I think this is a great idea. CVS make backup files of your
changes when you update from the central repo. Darcs could make
a backup bundle so you can unpull the pulled patches and apply
it to get back to square one.

| It's generally considered a good idea to "darcs record --all" before
| pulling if you're not sure there won't be any conflicts or anything.
| 
| Perhaps darcs should do this itself on pull, but put the patch somewhere
| other than in the repository patch sequence?

In general I have been *avoiding* recording, so that I don't get conflicts.  I avoid conflicts because they make Darcs crash.  So my modus operandi is to pull frequently, fix conflicts, record, and push.  Much like CVS really.

I'm not sure that this was an issue on the occasion I reported.  On this occasion I had only some tiny un-recorded changes, I believe. Anyway I have a frozen copy of the repository if you want to look at it.

Simon

I nominate this to be considered "resolved-in-unstable" because we now consider
fewer cases conflicts, hang in fewer cases, and create backup files in more
cases when there are conflicts.

I think we now address all points one that were raised here, and this could be a
separate issue report: 

When reviewing "whatsnew" after a conflicting pull, I don't believe there's a
way to tell the difference between the files that have changes because of a
conflict, and files that have pre-existing conflicts. 

We document that we use an exclamation point for this, but I couldn't create a
case to demonstrate that the other night...maybe I missed something.

Since no one objected to my recommendation last week that this be considered
"resolved-in-unstable" last week, I'm proceeding with marking it as such.

Just tweaking the resolved status to 'wont-fix' because this bug has settled on
an 'automatically record a backup bundle of working dir changes' which we never
actually implemented.  That was a bit confusing.

The 'resolution' was just to rely on the fact that darcs has fewer conflicts and
also makes backup files now.

I'm at ICFP, returning Mon 7 Sept.  Erratic email.

Simon

Attachments

• unnamed

Re-opening as requested