bugmonotone - Bugs: bug #16924, Feature request: `mtn copy`

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #16924: Feature request: `mtn copy`

Submitter:  Jack Lloyd <randombit>
Submitted:  Fri 23 Jun 2006 11:57:30 AM UTC
Votes: 1
 
Category:  command line UI Severity:  3 - Normal
Item Group:  feature request Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open
mtn version --full: 

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.

Jump to the original submission

  Spam posted by anonymous
Tue 25 Jul 2006 05:47:53 AM UTC, comment #5: 

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

Nathaniel Smith <njs>
Group Member
Mon 17 Jul 2006 01:26:12 AM UTC, comment #4: 

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...

Jack Lloyd <randombit>
Group Member
Mon 17 Jul 2006 12:55:20 AM UTC, comment #3: 

if I understand this correctly??


) Branch the file - In Place
) Delete a chunk of text from file
) Create new empty file
) Paste chunk of text into new empty file
) Add File... 

[Request] and somehow associate history of the chunk of text
from the previous file to the new file. 

madness and chaos shall be the most likly outcome...  :-)

-----------
Alternativly

) Branch the file (a)
) checkout branched (a) with a new name (b) into the same working directory.  this sounds a bit mad?
) Delete a chunk of text from (a)
) Delete the inverse of the chunk of text from (b)
) Forever more treat (a) and (b) as unique, seperate and unrelated files which cannot be merged back together.

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

----------------
Any solution must also cover the simple case which was put forth in bug #13810

which is to....
) Branch the file (a)
) checkout branched (a) with same/new name (b) into a DIFFERENT working directory.

in this case (b) maintains it's association with (a)???

---------------------------

I agree that splitting/refactoring a file is a common need


Erik MT <codehappy>
Group Member
Fri 23 Jun 2006 12:24:12 PM UTC, comment #2: 


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.

Jack Lloyd <randombit>
Group Member
Fri 23 Jun 2006 12:10:32 PM UTC, comment #1: 

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...

Nathaniel Smith <njs>
Group Member
Fri 23 Jun 2006 11:57:30 AM UTC, original submission:  


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).

Jack Lloyd <randombit>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There is 1 vote so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

Follows 1 latest change.

Date Changed by Updated Field Previous Value => Replaced by
2006-07-17 codehappy Carbon-Copy- Added codehappy

Back to the top

Powered by Savane 3.13-cf05.
Corresponding source code