[darcs-users] Request: porting patches advice (can I get rid of/ignore dependencies?)
droundy at abridgegame.org
Sun May 9 10:05:06 UTC 2004
On Sat, May 08, 2004 at 09:46:26AM -0700, Kevin Smith wrote:
> David Roundy wrote:
> >On Fri, May 07, 2004 at 08:30:25AM -0700, Kevin Smith wrote:
> >>That is, if I have patches A, B, and C which result in a repo with
> >>current contents of X; and I have patches D and E that result in a repo
> >>with current contents of Y; and X == Y (as measured by a recursive
> >>diff); then why can't I apply patch F to both repos?
> >Because darcs has no way of knowing that X == Y.
> >Also, a recursive diff is insufficient for proving (from darcs'
> >perspective) that the two repositories really are identical, since there
> >could be identical files whose names have been switched... so this
> >really is a case of "inexact patching", which is not what darcs does.
> >Fortunately, it *is* what patch does, so you can use patch for this kind
> >of application.
> Hm. To someone who still doesn't fully understand patch theory, that
> seems strange and limiting.
> Individual patches do not carry around a list of dependencies. When I try
> to apply patch F to the two repos above, how would darcs even know that
> it was or was not created by one of those repos?
Darcs can't handle a patch all by itself if it doesn't know what repo it
came from so it can look up the context, and if necesary adjust the patch.
If darcs doesn't have access to the originating repo, then it needs to have
a "patch bundle" (as created by send, or internally by push), which
contains the context, in terms of a list of patch IDs. Moreover, the
receiving repo from a send needs to itself have all the patches in the
context, which is why darcs send needs access to the target repo.
> Above is the meat of my message. Below is idle speculation.
> As a workaround, it seems like in the future darcs could support
> receiving a patch, applying it to the working directory, and then
> creating a new patch from it that would be recorded.
Without the context, there would be no way to know that this change was the
same as the original patch, so it would be a bug to give it the same patch
ID, since that would be great way to introduce corruption. *Something* in
the patch ID (i.e. name, date, comment or author) needs to be changed in
order to keep darcs from thinking it is the same change, if it ever the two
repositories are brought in regular contact (via a pull, push or send).
I'd say this is really a job for diff and patch, which if necesary one
could script to also copy over patch names. Darcs really only does
revision control with other darcs repositories having a common history, and
its patch format and the code it uses to apply it (which doesn't include
inexact patching) really isn't suited for other purposes.
More information about the darcs-users