[darcs-users] feedback on darcs conflict resolution

[Mark Stosberg]

I use darcs in a small team and these challeges sound familiar. I also
introduced darcs to my team, so I relate to the poster's position. We
also track patches with ticket numbers and work in a world of changing
priorities.

We deal with variations of unwanted dependencies frequently. There are
various resolutions depending on the situations. Solutions we use:

1. Developers understand the particular case and solve it themselves.
2. An uncommon or more complicated solution with several steps is
documented on the wiki
3. The team "darcs expert" is asked to handle it. (Me)

We have very little about darcs on the wiki, as there are few cases that
are especially challenging with it.

The "darcs expert" approach used fairly often. I make a judgment call
about whether the issue at had is a good match for trying to train the
particular developer on at that moment., or whether to address it
myself.

Years later, I'm still called on to deal with some uncommon cases, but
other developers understand and can address most other cases now. (I'm
not suggesting that takes years to figure these things out, just that I
don't expect everyone to ever quit asking for help completely).

We also try to improve the situation at a system level:

- Work with the customer to allow us to finish what we start, and keep
  priorities stable-- it's more productive and efficient for everyone
  when possible.

- Work to keep the patch pipeline short. The more works that are in
  progress, there more there is chance for problems. This is a more
  internal variation of the first issue. Outside of what the customer
  wants, it still takes some discipline to keep a clean set of repos.

It also sounds like there may be some human "conflict resolution"
factors at play. In the post I sensed a tone of exasperation, like "why
don't they get it, it's obvious to me?" Depending on the how solution
was shared, it may not have been in the easiest way for someone to hear.

That's why I think it could work well to just fix it yourself initially,
and then when there's less stress and everyone is calm, perhaps go over
a new wiki page about it, perhaps with some diagrams or sample play
repos, and also discuss the boundaries about what developers are
expected to fix on their own versus having a specialist work on.

Everyone has their strengths, and not everyone needs to be a darcs
expert.

I think with time other developers will pick up the same insights about
darcs workflows.

    Mark

OK, so there is one specific method we use sometimes that I'll share:
All the developers have their personal repos on the same server, along
with the "alpha" site. If someone pushes a troublesome patch, one option
we have is to "darcs oblit" the patch on the alpha site and in
everyone's repo except one, and then that person can unrecord/re-record
the patch. The "Start over" recipe is easy to understand addresses a
range of issues. It's also efficient to execute when everyone's repos
are on the same machine.

The common bash recipe there is easy enough to remember that it hasn't
been wiki-ized yet. It goes something like this:

for f in dev1 dev2 dev3; {
    su -m $f -c "cd /home/$f/trunk; darcs oblit -p 'RT#1234: badpatch';";
}