[darcs-users] some special amend-records

Ganesh Sittampalam ganesh at earth.li
Mon Apr 8 18:18:33 UTC 2013


Hi,

Some thoughts inline. It would probably make sense to start a wiki page
for this design at some point soon, under http://darcs.net/Ideas/

On 05/04/2013 22:12, Sebastian Fischer wrote:
> Dear all,
>
> it took me some time to mentally organize the different proposals. I'd
> like to summarize what I understood and discuss options for
> implementation.
>
> Originally, there was demand for splitting and merging named patches
> that are comprised of too many or too few patches respectively.
> Splitting is useful for pulling (or depending on) only parts of a
> patch (for example a utility function without the feature that
> introduced it.) Merging is useful to retroactively combine associated
> patches and may simplify diff output if merged patches add things that
> are removed by another merged patch.
>
>
> My impression is that problems arise because patches depend on full
> named patches rather than on the actual primitive patches that make
> relevant changes.
>

I agree that this is a real problem, but on the other hand atomic
changesets are important for keeping related changes together. We need
to be careful to keep that, otherwise you could for example end up
pulling the addition of a method to a class without the changes that
implement that method, or vice-versa.

>
> Darcs rebase allows to split and merge patches. But it also changes
> the identities of all descendant patches which was considered too
> disruptive.
>
>
> As alternative solution "patch groups" were proposed as a means to
> bundle certain patches under a user provided name. Like with branches
> in Git, it should be possible to add and remove patches from a patch
> group and users who have pulled a patch group should be able to follow
> such changes.
>
> My impression is that the whole repository can be viewed as a patch
> group that contains everything, so patch groups might be a
> generalization of repositories. Adding and removing patch groups from
> a working directory looks like switching branches in the same
> directory but more flexible. (My impression is that patch groups can
> be combined more flexibly than branches.)
>

That's a very good point about adding a feature to a whole repository.

I think it means patch groups can be used to subsume the history
tracking concept that you implemented as a separate tool, which would be
a nice result if it works out. It would be really great if it can also
give us a good UI for multi-branch repos.


> On Wed, Apr 3, 2013 at 7:06 PM, Ganesh Sittampalam <ganesh at earth.li
> <mailto:ganesh at earth.li>> wrote:
>
>     I think the general idea [of patch groups] is one that needs some
>     careful
>     design/exploration of the possibilities and in particular how it would
>     overlap with the other idea we've discussed, of declaring that patches
>     can supercede each other.
>
>
> I have looked at changeset evolution and phases in Mercurial. If I
> understand correctly, patch groups are a means to avoid changeset
> evolution. Instead of changing patches, new patches that (partially)
> revert old patches would be recorded and patch groups would hide
> unnecessary details, for example by producing combined diffs.

I don't think adding new patches to revert old ones is going to work too
well, because (X;X^-1) doesn't really behave the same as an identity
patch: it conflicts with anything that conflicts with X.

So my feeling is that patch groups will have to support a "remove this
patch" operation.

>
> On the other hand, changeset evolution is an alternative to patch
> groups. Instead of adding and removing patches to and from patch
> groups, we could have an evolving patch to which primitive patches
> would be amend-[un]recorded.
>
> The difference between named patches and patch groups might be that
> patch groups cannot have dependencies (if we decide so, which may be
> reasonable to avoid the aforementioned problem of too coarse grained
> dependencies.) Avoiding dependencies on complete patch groups
> presumably simplifies adding and removing patches from patch groups.
>
>      - can patch groups be hierarchical?
>
>
> I think it should be possible to add a patch group to another.
> Examples are adding a feature to the whole repository or incorporating
> common functionality into different patch groups. The question is how
> to represent this internally. I see two options:
>
> 1. When adding patch group g1 to patch group g2 add all patches of g1
> to g2 so patch groups are always flat.
>
> 2. keep a tree structure of patch groups that allows to observe which
> group was added to which.
>
> I'm not sure if a tree structure is useful from a user perspective, as
> I expect, e.g., diffs for a patch group to be accumulated and hence
> identical with options 1 or 2. Even if the tree structure is not
> useful for the UI, it may be more efficient to keep it. For example,
> comparing patch groups might benefit from recognizing (and not
> descending into) identical nested patch groups.

My feeling is that it is useful for the UI. Suppose I have groups  "Add
rebase suspend" ; "Add rebase unsuspend" etc, which collectively make up
"Add rebase". If I alter one of the smaller groups, I want that to be
reflected in the bigger one.

On the other hand it means that in the "repository as patch group" case,
altering one of the smaller groups implicitly alters the whole
repository, which could be surprising.

I think either way we'll need UI help to provide warnings in this kind
of case -  e.g. "altered group X; groups Y and Z implicitly altered as a
result".

>  
>
>      - is it allowed for them to overlap?
>
>
> Overlapping seems useful for the "incorporating common functionality
> into different patch groups" scenario. Overlapping does not change the
> underlying sets of primitive patches, so I think it is reasonable for
> patch groups to share patches or even nested groups. So rather than a
> tree of groups we would have a directed acyclic graph.

Agreed. One thing I think we should ban is non-contiguous patch groups,
i.e. having a group where the individual changes can't be commuted to be
next to each other.

For example consider the following sequence:

1: create X with contents "A"
2: change contents of X to "B"
3: change contents of X to "C"
4: change contents of X to "D"

if it we legal to have group G1 with just changes 1 and 3, it would be
very hard to manipulate. We could also create G2 with just changes 2 and
4, and end up with two groups that were implicitly dependent on each other.

On the other hand the following would be fine with the same groupings,
because we could commute them to bring the groups together:

1: create X with contents "A"
2: create Y with contents "B"
3: change contents of X to "C"
4: change contents of Y to "D"


>      - should we replace the current concept of patch names with patch
>     groups?
>
>
> Good question. On one hand patch groups have similar attributes to
> named patches (author, name, and possibly a summarizing description.)
> On the other hand patch groups may not be allowed to have dependencies
> which distinguishes them from named patches.
>
> It looks like named patches are like flat patch groups with
> dependencies and what I outlined are nested patch groups without
> dependencies. Assuming we want nesting without dependencies, I'm not
> sure if we should get rid of the former if we have the latter or keep
> both.
>

Hmm. My gut feeling is that having two overlapping and non-orthogonal
concepts is bad, so perhaps we should go all the way and having nesting
with dependencies.

Or (thinking out loud), perhaps nesting and dependencies are really the
same thing: patch group G depending on H seems similar in practice to G
containing H, even if they seem different conceptually.


> Compared with changeset evolution, I like about patch groups without
> dependencies that things that are depended upon never change. Patch
> groups look like a convenient way to exchange patches using similar
> workflows like changeset evolution avoiding some of the problems of
> evolution.
>
> What do you think? What are problems / corner cases to consider? How
> expensive is the implementation likely to be? Do you have alternatives
> in mind I did not mention?
>

It'll be a significant project, probably touching most of darcs' UI and
perhaps reworking a few of the intuitions that we present to users, but
it sounds doable.

As a starting point, we'll need to work out the patch semantics of the
operations on patch groups themselves.

Another thing to think about is whether we also want phases and whether
they can be kept sufficiently independent of patch groups that we can
implement them separately.

Cheers,

Ganesh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20130408/3c3b2b83/attachment.html>


More information about the darcs-users mailing list