[prev in list] [next in list] [prev in thread] [next in thread] 

List:       darcs-users
Subject:    Re: [darcs-users] 'darcs pull' hangs
From:       Adam Megacz <megacz () cs ! berkeley ! edu>
Date:       2007-11-10 20:59:56
Message-ID: x3lk9524vn.fsf () nowhere ! com
[Download RAW message or body]


"Eric Y. Kow" <eric.kow@gmail.com> writes:
>    http://wiki.darcs.net/index.html/ConflictsFAQ

Ah, I see.  By the way, although I'm sure the darcs developers think
of this as a conflict problem, it might be more useful for users to
rename this part of the page to DarcsTakesForever or something like
that.  It's often not even obvious to a new users that conflicts have
anything to do with the fact that darcs is taking forever, so they
wouldn't be likely to discover this useful page!

Also, in the "what triggers it" section, is this the "nesting depth"
or the "dependency depth"?  It seems like the latter conveys the
situation more accurately.  A very long string of patches depending on
each other is not unusual at all (in fact, very common, no? at least
it seems so for me).

Is a "conflict fight" different from a "conflict misery"?  It seems
like both of these are different from a "doppelganger patch".  So it
looks like there are four cases of "darcs takes forever" (ruling out
the easy cases that optimize can fix):

  - fighting conflicts
  - miserable conflicts
  - hidden conflicts
  - doppelganger conflicts

If it's okay, I will start a page DarcsTakesForever as a starting
point for people who encounter this problem and just want to know the
shortest step-by-step path to (a) classifying their problem and (b)
fixing it.

> after you have resolved the conflict, be sure to propagate patch
> resolving it to all the branches.

However, this isn't always reasonable... for example, in my case, I
use darcs to let students pull each week's chunk of a semester-long
programming project (as well as corrections and hints along the way).
So there are 22 "local branches" of my instructor repository, and I
cannot accept pushes back from the local branches (no student should
ever see another's code).  I also maintain my own mirror of each of
their branches, which they 'darcs send' to in order to turn in their
assignments.  It's all a rather nice way to show off darcs' abilities,
except for the conflict problem.

> Unfortunately, the only solution so far is to merge conflicting
> patches by hand, outside of darcs. In other words, you use darcs
> diff to generate a Unix diff for one of the conflicting branches and
> apply them to the repository via the 'patch' program.

This is exactly what I wound up doing (to the student's branch, on her
behalf).

> darcs pull --verbose --dry-run > /tmp/pull-output
> darcs pull --dry-run --summary

Hrm, I didn't realize how useful --verbose and --summary were in
combination with --dry-run.  Thank you for telling me about this!

> # darcs obliterate

Heh.

> Merging by hand :-(
> ===================
> darcs diff --repodir=../61ch-labs -p 'preparing for Emit lab' --unified > /tmp/emit.diff
> patch < /tmp/emit.diff
>
> Inspect the results, darcs record a new patch.  And if satisfied, discard the
> original 61ch-labs (hopefully, noone else is using a copy of that repository)

Yes, I actually wound up doing this.

Thanks again,

  - a

-- 
PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380

_______________________________________________
darcs-users mailing list
darcs-users@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-users
[prev in list] [next in list] [prev in thread] [next in thread]