Re: [Monotone-devel] Perhaps strange request: partial per-file commit

[Tim Woodall]

On Tue, 15 Jan 2008, Ralf S. Engelschall wrote:

> Sorry, in case this seems too strange for most of you, but it a
> "problem" I'm faced with mostly every day and I really would appreciate
> some additional support from Monotone. Let me describe...
>
> While I'm in "wild hacking mode" I adjust many source files. Once
> everthing works I have to decide on how to commit all my changes. Here
> the general golden rule for me is that all logically separate changes
> should be also committed separately. I usually never break this rule in
> all of my projects. So, if the changes do not overlap on a file-basis at
> all, it is trivial, of course:
>
>    $ mtn ci -m "description of logical change1" file11 ... file1N
>    $ mtn ci -m "description of logical change2" file21 ... file2N
>    $ mtn ci -m "description of logical change3" file31 ... file3N
>
> But what if change1 and change2 overlap in a file, say file11 == file21.
> My solution since many many years (there just with "cvs" and "svn", now
> with "mtn") is:
>
>    $ mtn diff file11 >change2
>    $ vi change2
>    [...remove all hunks which correlate to change1...]
>    $ patch -p0 -R <change2
>    $ mtn ci -m "description of logical change1" file11 ... file1N
>    $ patch -p0 <change2
>    $ mtn ci -m "description of logical change2" file21 ... file2N
>    $ mtn ci -m "description of logical change3" file31 ... file3N

I do this a lot as well. For one thing, when you've got a huge change it
makes it much easier for people to review.

But I don't think this is the way it should work.

There are two possible scenarios that I can see:

1. You compile, link and test each version before you commit - then the
above doesn't cause you any issues anyway, you've already broken it out.

2. You compile, link and test only the final version. Then that is what
you should be committing.

But what would be nice is, after the fact, to be able to create "virtual
versions" between the prior version and the one you've committed. You
shouldn't necessarily be able to (easily) check these virtual versions
out, just do diffs.

The way this could then work would be:

1. Commit everything.
   A___________B

2. Create "virtual versions"
         V1
   A____/  \___B
        \  /
         V2

Where initially V1 is the same as B and V2 is the same as A

3. Move or clone changes.
   If you want changes in lines 1-5 in V1, lines 16-33 in V1 and V2 and
   45-60 just in V2 then you would clone the lines 16-33 delta and move
   the lines 45-60 delta into V2

You'll need a way to add more "virtual versions"

           V1
         /    \
   A____/_ V2 _\___B
        \      /
          \   /
           V3

Where V3 will be another A initially that you can move/copy changes to
from V1 and V2.


I think these should be distinct from real versions because there's a
reasonable chance that they won't compile or wont work properly when
taken alone.

Tim.

--
God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t,"
and there was light.

     http://tjw.hn.org/      http://www.locofungus.btinternet.co.uk/