[darcs-users] some special amend-records

Ganesh Sittampalam ganesh at earth.li
Thu Apr 18 06:45:13 UTC 2013


Hi Sebastian,

Sorry for the delay replying.

I've snipped quite a bit of the conversation where it's not directly
relevant to my replies, hopefully the discussion still makes sense.

On 09/04/2013 11:57, Sebastian Fischer wrote:
> Thank you for your comments, Ganesh.
>
> I made an account on the Wiki and will make a page summarizing the
> proposal when initial ideas have settled.
>
> Should we talk about "changesets" instead of "patch groups"? The term
> "set" seems a better fit than "group" mathematically and "changeset"
> seems to be an established term for the thing we are talking about.

Sure.

> It seems there are two kinds of dependencies.
>
> 1. A change depends on another change if one cannot be applied without
> the other. For example, adding text to a file depends on creating that
> file and deleting a line depends on adding that line. Such
> dependencies can be computed automatically and we may call them
> "system dependencies".
>
> 2. A change can also depend on another change for other reasons. For
> example, the result of applying one might not compile without applying
> the other. As you point out, such dependencies are important to ensure
> consistent repositories. They cannot be computed automatically, so
> users need to specify them and can make mistakes. We may call these
> dependencies "user dependencies".
>

Yep - in Darcs as it is now, system dependencies indeed about
automatically and user dependencies can be added with the --ask-deps
flag to record/amend-record.

> My impression is that this distinction is important to handle mistakes
> when defining user dependencies. For example, when users bundle a
> change "feature and mistake", publish it, and others depend on this
> change then it is easy to revert the mistake if there are no system
> dependencies on it despite the user dependency. Without this
> distinction, I think patchgroups/changesets would not solve the
> original problem in the workflow of factis research.

I'm not sure I see this - in current darcs any user dependency on
"feature and mistake" is permanent in the sense that you can't retract a
published patch; all you can do is submit a new patch that undoes the
mistake. The dependencies will still be there, although perhaps they
won't matter.

If there's a system dependency on the mistake itself then undoing the
mistake becomes a little harder because by definition there's some kind
of conflict - e.g. the mistake added a line of text and the system
dependency is because a further patch edits that line. Undoing the
mistake now requires judgement as to what to do with the further edit.

>
>     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.
>
>
>
> Which part of history tracking would be subsumed? I don't think that
> push and pull would be tracked, for example. I notice that it is a bit
> unclear to me how history interacts with patchgroups/changesets. Maybe
> you have a clearer view?
>  

Sorry, this goes back to my opinion that history tracking isn't really
about tracking the state of a specific repository, but tracking the
state of a concept (e.g. "the release branch", "production" etc). Those
concepts could now be realised as changeset and the history of additions
and deletions to the group would be tracked because editing the contents
of a changeset would have to be a patch itself.

Posthooks could be used to implement the common case of tying the group
to a specific repository, i.e. you'd do an operation on the production
repository and the "production" changeset would be automatically updated.

>     So my feeling is that patch groups will have to support a "remove
>     this patch" operation.
>
>
>
> In my previous mail I was a bit unclear about this aspect. Initially I
> proposed to allow to "add and remove" patches and later I assumed that
> modifying or removing patches from changesets was not allowed.
>
> In retrospect, I think it is important to *not* modify or remove
> arbitrary patches from changesets (at least when they are public) in
> order to not destroy system dependencies. With a concept of phases
> that track which changesets are public, it seems possible to allow
> modification and removal of unpublished changesets but this seems to
> be orthogonal.
>

One thought here is that if a system dependency is removed by a
modification, the user should be prompted on whether to create a user
dependency instead.

> There may be a less powerful operation on changesets
> that addresses your point about conflicts of (X;X^-1) without
> destroying system dependencies on public changesets. Can we provide an
> operation "normalize changeset" that recomputes primitive patches from
> a combined diff? It seems that this will never destroy code because it
> does not change the effect of a changeset on the repository. Does this
> make sense?

I this will be very tricky - there's this general assumption in darcs
that operations are reversible which isn't true of normalization.  I
can't think of a concrete problem off the top of my head, but it just
feels undarcsish :-)

>
> For example, assume X^-1 is added to a changeset S containing X.
> Someone who pulls this change and has itself changes that depend on X
> will get a conflict that needs to be resolved before S can be
> normalized. Someone without changes that depend on X will not have to
> do anything. This is less intrusive than amending a patch
> corresponding to S which both potential users depend on.
>
> System dependencies may need to be recomputed, when normalizing, to
> depend on the new primitive patches. Which dependencies should be
> updated is a bit unclear to me.
>

BTW system dependencies in darcs at the moment are implicit and only
"computed" when darcs needs to commute two patches - the dependency
comes about because the commute fails. User dependencies are implemented
by artificially forcing commutes to fail.

>
>     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 it's quite natural. If I have merged the changeset "Add
> rebase" I expect my repository to change if I pull new changes to the
> changeset "Add rebase". I view this as similar to being on some Git
> branch and pulling changes to that branch.
>

Fair enough.

>  
>
>     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".
>
>
>
> Not sure if it's a warning but I agree that such output is useful. For
> example:
>
> Pulled changes to the following changesets:
>
>   * Add rebase
>       * Add rebase suspend

Agreed.

>
>>          - 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.
>
>
>
> Indeed. Should we even require that user dependencies must always
> subsume all system dependencies of the bundled primitive patches? In
> your example, this would mean that G1 and G2 must contain each other
> which means that they are the same changeset.
>
I guess this could be done with some automation to help calculate the
user dependencies from the system dependencies. One worry is that it
would be computationally expensive to do so, because it would have to
happen up front rather than at the point where the dependency was being
tested by some commute operation.

> This requirement is stronger than contiguousness. For example, it is
> no longer possible to record X^-1 in a changeset that does not contain
> X. Your other example (where lines 2 and 4 modify a different file in
> a different changeset) would still be supported though.
>
> One way to ensure that changesets contain all system dependencies
> seems to be to have a "current changeset" that is reflected in the
> working directory and used implicitly when recording changes. The
> system dependecies in the working directory are then automatically
> part of the current changeset.
>
> (Maybe, switching to a nested changeset should be possible if the
> changes in the working directory (system-)depend only on changes made
> by the nested changeset. Then nested changesets can be updated by
> first making them the current changeset.)

Sorry, I'm afraid I don't follow the last few paragraphs.

>  
>
>     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.
>
>
>  
> I consider phases (that track which changes are public, which are
> local, and which are secret) orthogonal. If normalization is the only
> operation that modifies changesets (and it turns out that it indeed
> never breaks system dependencies) we may not even need phases.
>

Yeah, that makes sense.

> I think of the current proposal as "changeset abstraction" and opposed
> to "changeset evolution". I think users should only see changesets and
> their accumulated diffs. Underlying primitive patches should be
> "abstracted away". System dependencies should be computed
> automatically and (probably) only among primitive patches. Additional
> user-defined dependencies specify which changes belong to which others
> and control which changes are pulled in the working directory of a
> repository.
>
> I wonder how such an abstract view on changesets corresponds to
> history. A changeset seems like a timeless bundle of changes where it
> is important what changes are made but not when and in which order
> they have been implemented.
>

I think that because the contents of changesets will themselves need to
be version controlled, the history of the changeset tells you how it
changed over time, whereas the current state is the timeless bundle of
changes.

>
> The outlined proposal seems quite intrusive to Darcs and I wonder if
> there is something simpler that could be done more quickly. My
> impression is that the distinction of "system dependencies" and "user
> dependencies" is necessary to solve factis's problem. Maybe it is also
> sufficient? Could we change dependencies in Darcs accordingly without
> adding a new concept of patchgroups/changesets?
>

I think the key thing factis need in addition is the ability to modify
both system and user dependencies after they are created.

As I understand factis' requirements, they are

(a) they have large patches in the history of their repo which they
would like to replace with a number of smaller ones that add up to the
same patch, and be able to propagate that replacement around easily.

and (I think less importantly)

(b) introduce some concept of groups of patches which can be
continuously updated as new work is done on features

Broadly I think (a) can be implemented either by "changeset abstraction"
or "changeset evolution" whereas (b) can only be implemented by
"changeset abstraction".

I suspect changeset evolution is easier to implement. However it would
still require a repository format upgrade of some form (as the evoluton
patches wouldn't be backwards compatible). I can't think of anything
that would be much simpler and still achieve goal (a).

Cheers,

Ganesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20130418/85256a06/attachment-0001.html>


More information about the darcs-users mailing list