Re: [Monotone-devel] Splitting a file and preserving history

[Nathaniel Smith]

On Tue, Feb 27, 2007 at 01:40:00PM -0800, Eric Anderson wrote:
> All,
>       Yesterday, while working on project, I wanted to split a file
> into two separate files.  I was hoping to preserve the history on one
> of the split out files so that things like annotate would tell you
> where various bits came from.  Unfortunately, I couldn't figure out a
> way to do this, and looking at the monotone history, when the same
> operation occurred (commands.cc -> cmd_*.cc) the new files were just
> added, and the old file had all the bits removed, losing easy access
> to the history information.
>       So I have two questions: 
> 
>    1) have I missed the feature somewhere? 

No.

>    2) does such a thing make sense in the current monotone structure?
>       It would be similar to mtn rename, but instead would be a copy.
>       If it makes sense, and seems valuable to others, can anyone give 
>       me a pointer to where I would go to add this feature?

It might make sense.  Be warned that you're talking about extending
the core history format -- i.e., modifying the revision file format,
updating the roster structure, etc. -- which is not to be done
lightly.  This is the code that cannot ever fail to notice any kind of
corruption, and where we don't get to ever change our minds without
having an 0.25->0.26 level of flag day.  (Actually, any change to it
at all is a kind of flag day, but changes that only break forward
compatibility, and only do that when people start using a particular
feature, are not as bad.)

The biggest question is what the semantics should be wrt merging.
(And, what the consequences of this are wrt history invariants.)
There really isn't any clear answer.  Suppose that you have copied a
file, and in parallel I have modified that file.  When we merge,
should my edits somehow find their way over into the new copy of the
file?  One can make a plausible argument either way, depending on the
situation...

The simplest thing to implement would certainly be that a copy is
exactly like an add for all history purposes, and the only effect is
that 'annotate' and 'log' will notice it when they reach the end of
the copy's history, and jump over to the original file's history at
that point.

The other option to consider is what git does -- don't record the fact
of a copy in history per se, but instead decide that noticing such
things is the job of a smart computer-assisted history inspection
interface.  I.e., teach annotate to look around and figure out where
those lines are on its own.  Since it's just presenting information
to the user, and not committing to maintain any invariants on this
information over time, etc., it's perfectly legitimate to make
guesses, point out to the user that while these lines are new now if
you look over here some very similar lines used to exist there, etc...
This is actually probably easier to implement, and might be more
useful in any case...

-- Nathaniel

-- 
"But suppose I am not willing to claim that.  For in fact pianos
are heavy, and very few persons can carry a piano all by themselves."