[darcs-users] feedback on darcs conflict resolution

[Eric Kow]

Hi all,

I got some fairly extensive feedback on darcs conflicts in a team and am forwarding it with the author's permission. Basically situation is that author is comfortable with Darcs but their team are not.

So my questions are basically more along the lines of: what can Darcs do to be more obvious?

Sounds like helpful stuff below.  Look especially at the two situations below.  Seems like the perfect sort of thing to mine as guiding scenarios.

Anonymised by default, but author is copied in case they want to respond or follow up.

Thanks,

Eric

PS. I think Petr's work on darcs annotate UI will address some of the issues

Begin forwarded message:
> 
> The actual resolving conflicts in darcs is pretty much a breeze.  Find
> v v v, chose what parts of the one or two versions you want to keep,
> record a new patch.  All of that is fine.  Even my slowest developer
> understands that.  The problem has to do with metadata associated with
> the patch and how to handle exceptional cases in the workflow.  To
> give you some background we have a setup like this:
> 
> one sandbox repo per developer (this is where patches are recorded)
> a development repo (this is where developers can share code)
> a deploy repo (this is where developers push code that is ready for
> testing, patches are pushed from development)
> a testing repo (this is the repo on the test box that holds what is
> currently in testing. patches are pulled from deploy)
> 
> There are more repos representing QA and production.
> 
> We have a ticketing system.  A developer must have a ticket to change
> code.  When he or she records code, the first part of the commit
> message must be the ticket number.  We push and pull based on the
> ticket numbers.  We pull/unpull tickets (unpulled tickets go back to
> the developers for more work) to/from the testing and qa boxes until
> we are certain that we have a set of tickets that can be pushed to
> production.  Tickets can only go to production if all of the patches
> go to production.  Once a ticket is in production, not changes can be
> recorded against that ticket.
> 
> As the team has grown we have started to run into problems where
> people are working on similar sections of the code.  Within the last
> week I have had to deal with the following two situations.
> 
> Situation 1
> 
> 1. Developer A pushed a patch for ticket 100 to development
> 2. Developer B pulled from developemdnt
> 3. Developer B did some work and recorded a patch for ticket 101
> 4. Ticket 101 had a higher priority than ticket 100, but it turned out
> that the patch for ticket 101 was dependent on ticket 100 (which was
> not finished).
> 5. I told the developer to unrecord his patch in his sandbox, unpull
> ticket 100 from his sandbox, fix the code so it worked properly, file
> a new ticket (102), and record the changes against 102; I would then
> pull the changes into the development repo and fix the conflicts that
> I knew would arise from the same code being in two patches and record
> the changes against ticket 101.
> 
> Step 5 was immediately obvious to me, but it took me two thirty minute
> sessions (on different days) to explain it to Developer B.  And even
> then, on the day I tweeted, he was confused when trying to promote
> patch 102 to the testing repo.  He thought the conflict resolving
> patch had to go as well (as opposed to understanding that the conflict
> resolution patch is supposed to go with the ticket 101 and that ticket
> 100 and 101 must now move together).
> 
> Situation 2
> 
> 1. Developer C pushed a patch to development for ticket 200
> 2. Developer B did not pull before working, and then recorded a patch
> for ticket 201
> 3. The two patches touched the same file in the same area, it refused
> to let Developer B push to development (i.e. there was a conflict)
> 4. After ascertaining that ticket 201 had a higher priority than
> ticket 200, I instructed Developer B to pull the patch for 200 into
> his sandbox, fix the conflicts, record the changes against ticket 200,
> and then try pushing to development again.
> 
> It took fifteen minutes to explain the how and why of this to the
> developer (even though it was obvious to me).  I then went back to my
> own work.  Two hours latter I checked up on Developer B.  He had done
> all sorts of things to his repo.  He had tried unpulling some patches
> and pulling others.  It was an ungodly mess.  I still do not know what
> it was he was trying to do (it was certainly not the clear steps I had
> told him to take).  I spent the next half hour fixing his repo and
> then five minutes performing the steps I told him to do in step 4.
> 
> It was after situation 2 that I posted that tweet.  As you can see
> Darcs itself isn't my problem.  It is getting my developers to wrap
> their heads around Darcs.  I have tried all manner of analogies and
> explanations to get them to grok what is going on, but they still
> treat Darcs like it is magic that is beyond their comprehension.
> 
> My only problems with Darcs is the speed (especially pulling from a
> remote repo) and the inability to get decent blame output (darcs
> annotate FILE has terrible output and crashes if the file has too many
> patches).  I will say that we are still using Darcs 1.  I want to
> upgrade to Darcs 2, but the developer who originally switch the team
> to Darcs told me before he left that they had not switched to Darcs 2
> because it was even slower.  He did mention that he had worked with
> the developers to speed it up, but that his last benchmarks still
> showed that it was too slow.  That was a year or so ago, so I have
> been meaning to try upgrading and see what if any speed issues remain,
> but I have had no time.

-- 
Eric Kow <http://erickow.com>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20120214/89f62feb/attachment.asc>