[darcs-devel] darcs patch: fix typo (and 3 more)

Eric Y. Kow eric.kow at gmail.com
Sun Aug 5 03:49:54 PDT 2007


Thanks!

> Maybe more controversial, it "works" for Unrecord / Unpull /
> Obliterate too, as in the meaning of 'deps' is reversed:
> 
>   darcs obliterate --match 'author Voldemort' --no-deps
> 
> will ask for all patches by Voldemort that can be obliterated
> without also obliterating any (depending) patches not by
> Voldemort. For me it's intuitive, but others might want to
> protest.

Sounds intuitive to me.  I'm going to take these and maybe rollback
later if this upsets anybody.  Comments?

Tommy, it might be worth adding this to the doc.
 
> Wed Aug  1 23:30:28 CEST 2007  Tommy Pettersson <ptp at lysator.liu.se>
>   * resurrect --no-deps [issue353]

I've had a look at the PatchChoice code and thought I might jot some
notes down.  Again, the usual warning applies.  There be holes, mistakes
and made-up stuff.

Patch choice and patch dependency
---------------------------------
Our goal is take patch dependencies into account when selecting patches
for pull, obliterate, etc.  For example, if you want to pull a patch,
darcs must make sure that you have pulled the patches it depends on.
Conversely, if you want to obliterate a patch, darcs must ensure that
anything which depends on it is obliterated.

First things first.  A PatchChoice consists of a patch number (for UI
purposes, e.g. "this is patch number 4"), a patch and a choice.  The
possible choices are:
  Just True  - "take it"
  Just False - "don't take it"
  Nothing    - "undecided"

> data TaggedPatch = TP Tag Patch
> data PatchChoice = PC TaggedPatch (Maybe Bool)

(*) That (Maybe Bool) could perhaps be switched to a custom data type
    for better documentation

When we are selecting patches, we are not just dealing with a list of
vanilla patches, but a list of annotated PatchChoices.  Now let's back
to our original objective: given a list of PatchChoices, we want to
modify that list to take patch dependencies into account.  In other
words, patch selection should be safe in that you should never be able
to select a patch which violates a dependency.  We model this notion of
patch choices + dependecies by splitting our list of PatchChoices into
three parts: first, middle and last.  These three parts describe the
order in which patches must be applied.  You can apply the first patches
without any constraints (they have no dependencies); you can apply the
middle patches only if you have applied the first ones; likewise, you
can apply the last patches only if you have applied the middle ones.

So how do we decide what goes where?  Intuitively, we want the first
patches to be the selected ones, the middle patches to be the undecided
ones and the last patches to be everything else.  This is a two stage
process: (i) we commute the selected patches and their dependencies into
'first' [this is called 'forcing', but don't let the name alarm you; it
is perfectly safe] (ii) we demote all the choices (selected patches
become undecided, and undecided patches become unselected; i don't yet
understand why we do this).  The basic idea is that if we have selected
something, we have implicitly selected the things it depends on.

However, what happens if the user modifies our selection with --no-deps?
Here the basic idea is flipped over: if our patch depends on something
(which is not explicitly selected), it is effectively not selected.
Recurse.  Whereas in the traditional approach, we grab the selected
patches and their dependencies, in the --no-deps approach, we ungrab any
selected patches that have dependencies.  This is implemented by forcing
any not-explicitly-selected patch into the 'last' category.  We commute
them out of the way and let them drag their dependencies along the for
ride.

Let's see how this plays out with an example.  Say we issued we are
pulling from a repo with following new patches:

 * bugfix a
 * some random patch
 * bugfix b which depends on bugfix a
 * bugfix c which depends on some random patch
 * other random patch
 * bugfix d which depends on bugfix c 

If we 'darcs pull -p bugfix', we will have
 d first  - a, random patch, b, c, d
 d last   - other random patch

If we 'darcs pull -p bugfix --no-deps' we will instead have
 n first - a, b
 n last  - random patch, c, other random patch, d

The point here is that even though 'bugfix c' was explicitly selected,
it gets deselected for its dependency on 'some random patch' (as
does bugfix d).  On the other hand, bugfix b is accepted because whilst
it does depend on something, the thing it depends on was explicitly
selected.

My view is a little hazy on this.  I suspect I'm missing out on how the
middle patches get used.  I had the impression that the patches were
ultimately divided in the following manner:
  * First:  All the selected patches and their dependencies
  * Middle: Undecided patches
  * Last:   Deselected patches

Of course, middle and last are very good, but once we have commited to a
choice ("I want patches #5, #8, and #42" or "I want all the patches
written by Harry"), the 'middle' patches become less interesting.  We're
already commited, so why do we want to bother with undecided patches?
Therefore, we must split the middle patches up among the first and the
last.  You're with us or against us.

-- 
Eric Kow                     http://www.loria.fr/~kow
PGP Key ID: 08AC04F9         Merci de corriger mon français.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://lists.osuosl.org/pipermail/darcs-devel/attachments/20070805/9e4d0559/attachment.pgp


More information about the darcs-devel mailing list