On 2004-10-30, David Roundy <droundy-pO0ceuy0HdYnY2huQ288Gg@xxxxxxxxxxxxxxxx>
wrote:
> On Fri, Oct 29, 2004 at 02:11:56PM +0000, Mark Stosberg wrote:
>> On 2004-10-29, David Roundy
>> <droundy-pO0ceuy0HdYnY2huQ288Gg@xxxxxxxxxxxxxxxx> 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/
|
