Re: [Gnu-arch-users] history of "forked" files

[Tom Lord]

    > From: Brian May <address@hidden>

    >     Tom> What do you mean by "have a.c's history as part of its own?"

    >     Tom> For example, suppose that patch-N predates the creation a1.c
    >     Tom> and a2.c and that you 'tla replay --reverse patch-N': do you
    >     Tom> want changes to a.c to be removed from _both_ a1.c and a2.c?

    >     Tom> or do you only mean: "If I prepare a report that shows all
    >     Tom> the changes ever made to a2.c, it will also show changes to
    >     Tom> a.c?"

    > subversion has a "copy" command that will copy the file with all of
    > its history, ie. create a branch of the file.

Subversion also does not have a coherent notion yet of how to handle
history-sensative-merging and it seems to me that the semantics of
that "copy" command are one of the areas where they have work to do.

As far as I can tell, there is a choice between having a system that
handles merging well and having a system that has the current
semantics of the subversion copy command.  Subversion and arch make
this choice differently.

As I remarked earlier:  for reporting purposes, you can easily add
custom log headers to record that a copy of a file is related to some
older file.

    > I think you could do this in arch(?) by somehow declaring a2.c was
    > derived from a.c in its initial version.

With a custom header.

    > I am not convinced myself that it would be worth the effort.

    > Why not just create a new a2.c file and rename a.c to a1.c?

That's where I am on this issue as well.

-t