Reported by Unknown User, Jun 23, 2006
(This entry was imported from the savannah tracker, original location: https://savannah.nongnu.org/bugs/index.php?16924) A very common work pattern for me is to split up the contents of files as they become large (ie, src1.c -> src1.c, src2.c, each with some sizeable portion of the contents of the previous src1.c). Obviously this split is easy to accomplish with a (OS-level) copy command followed by an add of the newly copied file. However, this means Monotone 'loses' the change history of the new file, because it doesn't know that the content is not actually new, just moved from a different place. Is there some other way to accomplish this that I'm not thinking of? I'm not terribly familiar with the branching commands, so I could believe there is some way to do this (though, if so, documenting it in a 'Tricks & Tips' section of the manual would be nice). monotone version: ----------------- monotone 0.27 (base revision: 341e4a18c594cec49896fa97bd4e74de7bee5827) Running on : Linux 2.6.16-1.2111_FC4 #1 Sat May 20 19:59:40 EDT 2006 i686 C++ compiler : GNU C++ version 4.0.2 20051125 (Red Hat 4.0.2-8) C++ standard library: GNU libstdc++ version 20051125 Boost version : 1_32 Changes since base revision: format_version "1" new_manifest [8e9ac81ef37aa9c0334b97d46467a8ee61450078] old_revision [341e4a18c594cec49896fa97bd4e74de7bee5827] Generated from data cached in the distribution; further changes may have been made.
Comment 1 by Unknown User, Jun 23, 2006
There is no way to record this in the history right now. We've been very cautious about adding something like that, because the semantics with respect to merging are _very_ unclear, perhaps unsolubly so. (This is discussed a bit at the end of http://venge.net/monotone/wiki/HistoryBlueSky ) For just tracking through logs or annotate, it might make sense to add something purely advisory to the revision format. It might also make sense to do guessing like git does, which can be done entirely post-hoc. In any case, we're aware of the general use case, but don't have any immediate plans to work on it, because it's not clear what to actually do. Thanks for making sure it's in the tracker here, though...
Comment 2 by Unknown User, Jun 23, 2006
Hrm, too bad. Do you happen to have handy a link to any list or IRC archives that discuss this? I can certainly believe, in the abstract, that there are some very difficult cases involved, but I'd like to understand the issue better.
Comment 3 by Unknown User, Jul 17, 2006
Perhaps the way I put it was not clear, I envisioned my actual request more much along the lines of "What about creating (b) as a completly independent file which simply has a copy/duplicate of the history of (a) but is not treated as a branch of (a)" TBH, I'm not entirely sure about the semantics that Monotone uses for its history, and I'm probably using too much of the OpenCM semantics since the systems are vaguely related - in OpenCM, a file copy was just like any other ancestor, so, for example: a (rev1) line1 line2 -> a (rev2) line1 b (rev1) line2 would be represented as "rev2 of a is based on rev1 of a, with a diff of -line2; rev1 of b is based on rev1 of a, with a diff of -line1" (which I think matches up with what your third suggestion was). This seems most logical (to me), in that doing a history of b later would show it's history leading back through to a rev1, at which point its history graph merges with the history of a. This seemed to work in OpenCM just fine, though potentially we simply never found out about the show-stopper problems njs refered to...
Comment 4 by Unknown User, Jul 25, 2006
Unfortunately, "creating (b) as a completly independent file which simply has a copy/duplicate of the history of (a) but is not treated as a branch of (a)" is not something that makes any sense in the vocabulary monotone uses to describe history :-). First, remember that trees are what have histories, not files. You can derive a file history by tracking its identity through the tree history, but it is not a fundamental concept. So you can't just "create a new file with a copy of the history" -- the only thing that makes sense to do is to create a new tree (revision) with a note that there is a new file (b), that is a copy of file (a). That part is straightforward, the problem is what semantics to use for such an operation. In particular, its semantics when merging are really unclear. Suppose you merge your revision with the copy in it with another revision that modified (a) -- should the changes be merged into (b)? What if the change is "rename"? ...or "delete"?