[darcs-users] Re: request for clear docs for 'push' and conflicts

[Mark Stosberg]

On 2004-10-30, David Roundy <droundy at abridgegame.org> wrote:
> On Fri, Oct 29, 2004 at 02:11:56PM +0000, Mark Stosberg wrote:
>> On 2004-10-29, David Roundy <droundy at abridgegame.org> wrote:
>> > On Thu, Oct 28, 2004 at 04:39:58PM +0000, Mark Stosberg wrote:
>> >> Hello,
>> >> 
>> >> I'd like to ask one of the more experienced people here to update the
>> >> docs for 'push' to explain what happens when there is a conflict. 
>> >> 
>> >> I created this myself with some play archives. darcs will report
>> >> that the push succeeded, but also that there are conflicts. 
>> >> 
>> >> But what state is the remote repo in after this? The local one? What
>> >> needs to happen to resolve the conflict?
>> >
>> > I've added a paragraph to the 'push' documentation.  If it's unclear, ask
>> > again...
>> 
>> Thank you very much. I'm still unclear on one point in the explanation:
>> 
>> "perhaps by pulling the conflicting patch"
>> 
>> How do I know which patch is conflicting? The feedback I get from darcs only
>> tells me the conflicted files, which could be in many patches.
>
> There's no way to know which patches conflict.  I would pull all patches,
> since this would make your local repository a mirror of the remote one
> (which you pushed to).  If you don't *want* all those patches, I'd do this
> in a clone.

Thanks. With these explanations, I've just submitted a patch to the
'apply' and 'push' documentation to clarify them further. I think there
are a few remaining bits to iron out:

1. Is it true that this is another case that should be built into:
	darcs init --public vs. darcs init --working ?

  It seems like for working repos, you want to default to
  resolving conflicts, but for public repos you want to default to not
  resolving the conflicts. 

  If these init options are much in the distance, it would be nice to
  have  a suggestion for this defaults cases in the manual. 

2. Let me make sure I understand what "--no-resolve-conflict" does when
  used on a push:

  The conflict is not worked in the working directory or in the remote repo,
  but darcs "knows" there is a conflict. It is expected that my working
  repo will default to resolving conflicts, while the remote won't. 

  Thus, when I pull the conflicting patch (which mean pulling all
  patches) from the remote repo, /then/ conflict markers appear
  in my working repo, which I can resolve and resubmit. 

3. And for "--resolve-conflicts": If my remote repo is set to resolve 
   conflicts and I push to it, I will still get a warning that there
   is a conflict, but it will only be marked in the remote repo
   not my working repo. 

   I basically can't fix this remotely, because if I /then/ try to pull
   from remote repo, darcs will report 'No Changes!" despite that the
   contents of one of my files differs from the conflicting file 
   in the remote repo. (That's confusing! I expected it would pull down 
   the conflicted file). 

#########

Some observations:

1. The default for conflict resolution for 'apply' is not documented
   anywhere that I could find.

2. It makes sense to me to create the 'defaults' file as part of init,
   with the current defaults. This serves as documentation, but it also
   means that if the darcs defaults ever change, people will get the
   defaults they are used to. 

3. There out to be some part of darcs that verifies that contents of the
   'defaults' file are valid.
   I added 'record wrong' to mine to test it. 'darcs check' did not
   detect a problem and even 'darcs record' worked without complaint. 

4. This whole experience speaks to me about the importance of making it 
   easy to init public and working repos with different defaults. 


   Mark


-- 
http://mark.stosberg.com/