monotone - 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)
|
Jump to the original submission
Spam posted by anonymous | |
Tue 25 Jul 2006 05:47:53 AM UTC, comment #5: |
Nathaniel Smith <njs> |
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)"
|
Jack Lloyd <randombit> |
Mon 17 Jul 2006 12:55:20 AM UTC, comment #3: if I understand this correctly??
|
Erik MT <codehappy> |
Fri 23 Jun 2006 12:24:12 PM UTC, comment #2:
|
Jack Lloyd <randombit> |
Fri 23 Jun 2006 12:10:32 PM UTC, comment #1: There is no way to record this in the history right now.
|
Nathaniel Smith <njs> |
Fri 23 Jun 2006 11:57:30 AM UTC, original submission:
|
Jack Lloyd <randombit> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
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 |
Powered by Savane 3.13-4448.
Corresponding source code
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"?