dan at ag-projects.com
Thu Mar 5 19:58:56 UTC 2009
On Wednesday 04 March 2009, Eric Kow wrote:
> On Wed, Mar 04, 2009 at 18:47:22 +1100, Trent W. Buck wrote:
> > Yes, it can be worked around. But sometimes this is terribly
> > inconvenient and "I know better than you, Darcs". Particularly when
> > I both ends are private repos to which only I have access -- I can go
> > into details regarding use cases in a follow-up post if you like.
> I'd be curious to learn more about this, i.e. where it would be
> inconvenient to darcs pull and resolve conflicts locally instead
> of pushing to the other end.
> I won't oppose the move if there is a general clamour for push
> --allow-conflicts and --mark-conflicts (which would be a ProbablyEasy
> bug to fix along with the darcs format flag propagation), but my
> personal vote is for the status quo (plus maybe an FAQ update)
I also think that the status quo is clearer and safer. In a general use
pattern, it's harder to check and resolve conflicts in a remote
repository, compared to a local repository. Also considering that a
repository which is pushes to, is generally used as a central repository
for synchronizing between developers and the expectancy is that the
repository is consistent and without conflicts.
I do not see a problem with having the allow/mark options to push as well,
for people who know better and really need this, but I think push should
keep --dont-allow-conflicts as the default. Not only it is safer, but
also people are used to this behavior. My current expectancy of push is
to fail if there is a conflict and not change the remote repo. If that
default behavior would change, I could easily miss that I pushed a
conflict to a remote repo and brought it to an inconsistent state.
More information about the darcs-users