[darcs-users] [dream] byte-oriented hunk?

Junio C Hamano junkio at cox.net
Thu Apr 7 23:57:00 UTC 2005


This is not even a wishlist item but I just got curious about
the feasibility of one change I dreamt about, and the extent of
damage that may cause to the current darcs implementation.

Looking at the contents of _darcs/ directory, darcs patch
commute algebra seems to operate without traditional diff/patch
style context, but with the precise information on which part of
the file was changed how.  However the way it specifies "which
part of the file was changed" is line oriented.  I am wondering
if it is fundamentaly wrong if an option to do this in a byte
oriented fashion were added; and if it is possible, I am
guessing that probably a different patch format needs to be
introduced, breaking backward compatibility.

Let me explain the situation that got interested me in this
issue.  At work, I had a project that had "foo" program.  I
needed to add "bar" and also later "baz" programs.

So a part of the patch to add "bar" looked like this, and went
into my work-in-progress Darcs repository "wip" two weeks ago:

    --- ./Makefile
    +++ ./Makefile
    @@ -1,7 +1,8 @@
    -TARGET = foo
    +TARGET = foo bar

     all:: $(TARGET)
     clean::
            rm -f $(TARGET) *.o *.a *~

     foo: foo.o
    +bar: bar.o

I had this in my "wip" but "bar" is still not ready for public
consumption.  I kept working on other parts of the system.  Then
I wrote and recorded "baz" change, which was more urgent.  Part
of it looked like this:

    --- ./Makefile
    +++ ./Makefile
    @@ -1,4 +1,4 @@
    -TARGET = foo bar
    +TARGET = foo bar baz

     all:: $(TARGET)
     clean::
    @@ -6,3 +6,4 @@

     foo: foo.o
     bar: bar.o
    +baz: baz.o

Since two patches overlap on the TARGET line, this makes "baz"
change dependent on "bar" change, preventing me from pulling
only "baz" change to my testing repository from "wip" repository
while leaving unfit-for-public-consumption "bar" change alone.
If the patch commuting (and patch recording as the prerequisite
for this) were not done line-by-line but byte-by-byte, I presume
I would not have to had to deal with this dependency and pull
only "baz" changes out of "wip" repository [*].

Or am I just dreaming?

[Footnote]

* The way I dealt with this dependency within the constraint of
  the current darcs was as follows:

 (1) unrecord "baz" change and save "darcs diff -u" output to
     the safe place.  Run "patch -R" to make the working
     directory and the "wip" repo before "baz" change was
     recorded.

 (2) unrecord "bar" change (remember that this was not pulled
     out of "wip" repository yet).  Run "patch -R" to make the
     working directory and the "wip" repo forget about "bar"
     change, still keeping all the changes since "bar" intact.

 (3) Rewrite Makefile as follows:

    --- Makefile
    +++ Makefile
    @@ -1,4 +1,5 @@
    -TARGET = foo
    +TARGET :=
    +TARGET += foo

     all:: $(TARGET)
     clean::

 (4) Commit the above change with patch name "Split lines to
     avoid unnecessary dependencies".

 (5) Apply "bar" change saved in step (2) with "patch", which
     would result in a conflict on the Makefile.  Resolve it by
     editing the Makefile as follows:

    --- Makefile
    +++ Makefile
    @@ -1,8 +1,10 @@
     TARGET :=
     TARGET += foo
    +TARGET += bar

     all:: $(TARGET)
     clean::
            rm -f $(TARGET) *.o *.a *~

     foo: foo.o
    +bar: bar.o

 (6) Record this as "bar" change.

 (7) Apply "baz" change saved in step (1) with "patch", which
     would result in a conflict on the Makefile.  Resolve it by
     editing the Makefile as follows:

    --- Makefile
    +++ Makefile
    @@ -1,6 +1,7 @@
     TARGET :=
     TARGET += foo
     TARGET += bar
    +TARGET += baz

     all:: $(TARGET)
     clean::
    @@ -8,3 +9,4 @@

     foo: foo.o
     bar: bar.o
    +baz: baz.o

 (8) Record this as "baz" change.

 (9) Now "baz" change can be pulled without "bar" change.
     Obviously you need "Split lines to avoid unnecessary
     dependencies" patch, but this way the testing repository
     does not need to know about "bar" yet.

I think the above would be a good item to add to Tips-And-Tricks
if it is not there yet.  The short version of the advice would
be:

    If you have a list of things that can independently added
    during the course of development, try to find a way for the
    host language to describe each item on a separate file.
    That way you can avoid unnecessary dependencies between a
    patch that adds one item to the list and another that adds a
    different item to the list.






More information about the darcs-users mailing list