This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
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..
this is not maven related but rather related to the version control you are using. Which one is it? hg/git/svn?
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?
ok, let's just reassign and see what happens
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.
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)
> 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
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..
(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.
And i am gratefull for, and will use those steps from now on. I did not intend to sound hostile.