Issue 46: Feature request: `mtn copy` - A distributed version control system

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"?