logo       
Google Custom Search
    AddThis Social Bookmark Button
-->

Re: request for clear docs for 'push' and conflicts: msg#00651

Subject: Re: request for clear docs for 'push' and conflicts
On 2004-10-30, David Roundy <droundy-pO0ceuy0HdYnY2huQ288Gg@xxxxxxxxxxxxxxxx> 
wrote:
>
> I'm not sure that that is always the case.  A public repo might still be
> one in which you actually make changes directly, in which case you'd want
> changes to be marked there.  I vaguely imagine three sorts of repos:
>
> public: unpull etc not allowed, pull not allowed, --no-resolve-conflicts
> working: unpull etc not allowed
> private: unpull etc ARE allowed
>
> But I'm not entirely sure.  I have a vague feeling that I'm missing
> something...

Why would 'pulling' by dis-allowed for a public repo? That's how I
update from the darcs repo. :)

> Right.  Darcs internally doesn't apply any of the changes caused by
> conflicting (primitive) patches, but knows that there is a conflict.  When
> you pull a patch that has a conflict, either with your local patches or
> local changes, or with another patch in the repo from which you are
> pulling, darcs marks the conflicts for you.  Darcs resolve does the same
> thing.
>
> --(no-)resolve-conflicts is something of a misnomer.  What darcs really
> does is *mark* conflicts in the working directory.  :(

That seems like an important semantic difference. It seems like it could
be worth updating these names, and deprecating but supporting the old
ones. 

Should the descriptions be updated at any rate? Currently the wording
is:

 "try to resolve conflicts"

Is the word "try" appropriate here? If darcs knows there is a conflict, 
in what case would it /not/ be able to mark it? File and directory adds and 
deletions
come to mind, but those are marked in "--summary". Is this more accurate?: 

 "mark conflicts"

> The default is to resolve conflicts.

I'm submitting a patch to document this.  

> Hmmm.  Not a bad idea, but unfortunately this (defaults) information isn't
> currently stored in a usefully accessible manner.  It would be nice to fix
> this, and wouldn't be that hard, but I'm trying to avoid doing anything
> "interesting" myself before 1.0.0 is released...  Other people can do
> "interesting" development, and I may merge it before 1.0.0, but I need to
> keep myself focussed.

According to the "TODO" list, there is nothing left to do before 1.0. :)

        Mark

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


<Prev in Thread] Current Thread [Next in Thread>