On Mon, Nov 07, 2005 at 11:31:57AM -0600, Richard A. Smith wrote: > Darcs by default won't allow a push to cause a conflict. Thats why I > went to the master and did a pull from my local. So if I do a record > I'm going to introduce a local modification into the master repo. And > I'm looking for advice on if thats bad or not.
It's not the end of the world. Nothing bad is likely to happen. It's just not the recommended workflow. Don't do it again :-). Reason being that by permitting a conflict on the master in the first place, you have the potential to infuriate your collaborators by propagating conflicts to their repos. It's that conflict on the master which is the problem, not the fact that you are recording a patch on the master. Rule of thumb: if you have to manually SSH to the master for /any reason, including pulls/, you are probably doing something bad. I remember getting into horrible situations before Darcs started preventing conflicting pushes, where several developers would get the conflict, resolve it, and then we'd have to resolve a bunch of conflicting conflict resolutions. It's a feature. Don't try to work around it. The preferred route is to do exactly what the CVS/SVN people do: pull the conflict into your local repo, resolve it there, and then push the resolution up to the master along with your original patch. That way no-one else ever sees the conflict. In general, if you're working with a centralised repo, it's helpful to always pull before you push (but /after/ you record, so that it's easy to reverse the pull if you decide you didn't want that patch after all) just as with CVS/SVN one tends to update before committing. If the pull flags up conflicts, you then have the choice of creating a new patch to remedy them, or amend-recording your existing patch (/only/ since you haven't yet pushed it anywhere). -- Jamie Webb _______________________________________________ darcs-users mailing list [email protected] http://www.abridgegame.org/mailman/listinfo/darcs-users
