bzr copy (Re: Weekly 0.10 release status)

[Andrew Bennetts]

Jelmer Vernooij wrote:
> On Tue, 2006-08-15 at 23:00 +1000, Andrew Bennetts wrote:
[...]
> 
> > (I don't have a strong opinion on this feature; it'd be nice I guess, but I
> > doubt I'd ever actually use it, so I don't care if it's in 1.0 or not.  I know I
> > haven't seen "svn copy" used except for branching before, but I'm curious to
> > hear about people who have and found it useful.)
> The main use case (at least for me) is tracking history when splitting
> large files. 

By "tracking history", you just mean you want better output from log and
annotate, or are you also thinking of merges?

Also, if it's really about "splitting" files, I wonder if "bzr split" would be a
better name.

For that matter, I wonder if there's a better way to represent that than by
recording "THIS-FILE is a copy of THAT-FILE"?

<begin handwaving>

If there's a file ORIGINAL like this:

    AAAAAA
    AAAAAA
    AAAAAA
    BBBBBB
    BBBBBB
    BBBBBB

That I want to split like this:

NEW_A:

    AAAAAA
    AAAAAA
    AAAAAA

NEW_B:

    BBBBBB
    BBBBBB
    BBBBBB

Then it'd be really cool if I could merge from a branch where ORIGINAL has been
changed like this:

    AAAAAA
    NEW A STUFF
    AAAAAA
    AAAAAA
    BBBBBB
    MODIFIED B STUFF
    BBBBBB

And have the new and modified lines merge into the right files.  I don't think a
simple "THIS-FILE is a copy of THAT-FILE" is a rich enough way to express what's
needed to make this happen.

In principle I suppose bzr could have smarts so that if you do:

    bzr copy ORIGINAL NEW
    # user edits ORIGINAL and NEW
    bzr commit

It would then compare the ORIGINAL and NEW you're commiting with the ORIGINAL in
the previous revision, and categorise each line as:

    * kept in ORIGINAL
    * new in ORIGINAL in this revision
    * new in NEW in this revision
    * copied from ORIGINAL to NEW in this revision (like "new in NEW", except
      for log and annotate)
    * moved from ORIGINAL to NEW

(and also take note of the lines in the previous revision of ORIGINAL no longer
present anywhere, I suppose).

So rather than recording that "NEW is a copy of ORIGINAL", it would be recording
"these lines were split out of ORIGINAL and into NEW".

Then if there's a merge like my example above, then bzr could, in principle, put
the new and modified lines in the right places automatically.

Implementing this efficiently and correctly is left as an exercise for the
reader...

<end handwaving>

-Andrew.