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." _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
