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. -- Dan _______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
