Re: [Gnu-arch-users] Ongoing Comparison Between Version Control Systems

[Tom Lord]

    > From: Aspect <address@hidden>

    > no, peter has a point here -- the case where you are splitting
    > up a document is valid. It is common when refactoring to pull a
    > chunk of code out of one file and into another, which produces
    > two partial descendents of the original file. I can't see any
    > other practical way to represent this than the copy operation
    > (or more precisely, copy+patches).

    > Arguably the "split" is the more interesting operation here --
    > but it seems to me that with the inclusion of the
    > "Copied-Files:" ChangeLog syntax (as already suggested by
    > someone in this thread), tracing file history in this manner
    > would be trivial. Unless there is another way, and I just
    > haven't thought of it ..

It would be fairly easy, not trivial.  It would add new code and
complexity to a system that still has, for the most part, the virtue
of simplicity.  It would add user-visible hair to the conceptual 
entity "the state of a project tree".

The problem is, while it's easy to talk about "representing that
information" and even to conjure up certain in-principle uses for it, 
it's: 

        a) not a feature that I've ever seriously missed in practice

        b) not a feature I've heard of anyone else seriously missing
           in practice 

        c) not a feature I've heard any really compelling uses for

        d) not a feature that interacts terribly well with the way
           that diffing and patching actually works (since the radical
           edits after a "split" mostly render those tools useless)

It's not like it hasn't come up for me either.  I certainly _have_
(more than once) gone through the exercise of:

        1) start with some actively developed piece of software

        2) refactor the code wildly, splitting files in all kinds of
           ways 

        3) propogated changes from the original software to my newly
           refactored software

It couldn't have been automated much.  My refactored code had diverged
enough (and it didn't take much) that it was basically a by-hand
process.  I'm not too optimistic that tools could have helped more
than they did and I'm certainly impressed by the
complexity-divided-by-value of trying to implement tools that might.

Somewhat related is the idea of doing revision control not on text
files at all, but instead on program entities --- "changes to the
function foo", perhaps even where "changes" means things like "add a
new parameter" or "change the function name" rather than "change line
3".

There was a research group at IBM that went a little ways down that
path before stopping, as I recall.  There's some current research at
SunLabs that might dovetail against such work (their work is on
semi-automating high-level transformations).  The Eclipse project,
I've been told, is doing a little of this.  In general, I think it's
impossible to go terribly far down that path while working with a
language who's surface syntax is text rather than structures or whose
macro definitions (if applicable) may not be visible to the editor --
oh yeah, you'll need a new editor, too, and it's a tricky exercise to
make a structure editor that feels as nice as a text editor.  Perhaps,
as would seem to be the assumption of the eclispe work, there's
intersection between the practically achievable results in that
direction and the shockingly useful results.

Above all, I want to caution against the presumption that because
Subversion history records sorta-kinda capture that information, that
therefore it is suddenly an important feature for revision control
systems to implement.  For example, another recent gnu-arch-users
thread has pointed out some rather serious questions about the closely
related area of how merging works in Subversion.

It is an interesting area to speculate about, though, and if you come
up with something both practical and obviously useful --- well, I
certainly hope we'll sit up and take notice.

-t