Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 218875 - Allow copying file without telling mercurial!
Allow copying file without telling mercurial!
Status: NEW
Product: versioncontrol
Classification: Unclassified
Component: Mercurial
7.3
PC Windows 7 x64
: P3 with 1 vote (vote)
: TBD
Assigned To: Ondrej Vrabec
issues@versioncontrol
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-24 06:58 UTC by akobberup
Modified: 2012-09-24 07:53 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description akobberup 2012-09-24 06:58:49 UTC
It should be posible to make a copy of a class without the IDE telling maven (and thus dragging the history of the old file with the new one).

Today i took a copy of a file and renamed the copy and used it in another context, while one of my coworkers updated the old file. This caused all sorts of merge problems, as maven saw that his changes to the common parent were before (in time) i made the copy, so the changes should be merged into the new file.

Were i given the choice, maven should just have been told that this were a new file, so my coworker should not have to merge (or in fact NOT merge) changes into a new file..
Comment 1 Milos Kleint 2012-09-24 07:03:41 UTC
this is not maven related but rather related to the version control you are using. Which one is it? hg/git/svn?
Comment 2 akobberup 2012-09-24 07:06:25 UTC
Shoot! Sorry - were up to late watching football last night!

It should have been mercurial everywhere i typed maven.
Should i close this issue and create a new and correct one?
Comment 3 Milos Kleint 2012-09-24 07:13:06 UTC
ok, let's just reassign and see what happens
Comment 4 Ondrej Vrabec 2012-09-24 07:19:21 UTC
You always have a choice to revert the copy. Simply run Mercurial -> Revert and the history for the copied file will be forgotten, the file will be removed from mercurial metadata and appear as completely new for mercurial.
Comment 5 akobberup 2012-09-24 07:29:14 UTC
When doing so, i am prompted to choose which revision i would like to revert to. How will selecting one of the previous revisions make the history for the file go away?

My guess would had been to invoke hg remove -Af, on the copy thus removing the file from mercurial, and then adding it again.
However this still seems a bit cumbersome, and imo could be done a bit more elegant by simply not letting hg know that the file is copied in the first place. (this should offcause be an option)
Comment 6 Ondrej Vrabec 2012-09-24 07:33:07 UTC
> When doing so, i am prompted to choose which revision i would like to revert
> to. How will selecting one of the previous revisions make the history for the
> file go away?
By default the parent of the working copy is selected as the revision to revert to. And with a copied file selected the result is equivalent to "hg rm -A". Try it yourself: hg revert -r . COPIED_FILE
Comment 7 akobberup 2012-09-24 07:43:16 UTC
Fair enough. 
But if the file has been comitted (as local-copy), it will have the previous revisions as the file it is copied from.

I guess that i just have to do these extra steps (btw remember to remove the checkmark in "remove newly made files and folders" when reverting) if copying files around and not wanting to drag along the history.

My point however still is that imo this could be made more elegant by allowing a choice in the refactor-copy dialog of whether to tell hg about the copy or not..
Comment 8 Ondrej Vrabec 2012-09-24 07:50:33 UTC
(In reply to comment #7)
> My point however still is that imo this could be made more elegant by allowing
> a choice in the refactor-copy dialog of whether to tell hg about the copy or
> not..
Sure, that's why i left it open. I do not argue with you, i'm just giving you the steps to work around the issue.
Comment 9 akobberup 2012-09-24 07:53:21 UTC
And i am gratefull for, and will use those steps from now on. I did not intend to sound hostile.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo