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. 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.) On Wed, Apr 3, 2013 at 7:06 PM, Ganesh Sittampalam <gan...@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. 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. > - 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. > - 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. 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? Best regards, Sebastian
_______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
