Open GoogleCodeExporter opened 8 years ago
Eclipse might not know that file exists yet. Did you refresh your workspace? In
navigator view select the folder you expect it to be in and press F5
Original comment by johnpeb@gmail.com
on 2 Aug 2012 at 1:09
Yes, I tried to refresh to workspace and also the folder it is in.
Also closing and opening the project doesn't work.
It's really easy to reproduce:
- Create a project and add a file
- Commit it to a repository
- Open Windows Explorer and change the name (in my case it's a name with a
lower case character to upper case, e.g. vtresc.c to vtresC.c)
- After a refresh the icon repository_rep disappears.
- It is not possible to add the "new" file to the repository from eclipse.
- It lost track of the file, also changing the file and commiting again doesn't
work.
Original comment by ronald.k...@kvernelandgroup.com
on 2 Aug 2012 at 1:21
The issue you're seeing is the case insensitive property of windows filesystems
- Mercurial sees the renamed file as the old file.
One way to do a rename changing only the case of the filename:
- make a backup of the file
- delete the file
- commit the deletion
- restore the file from backup and give it the new name
- add and commit
Original comment by johnpeb@gmail.com
on 2 Aug 2012 at 1:37
Ok, but why is it then working ok under turtoiseHG or command line.
Original comment by ronald.k...@kvernelandgroup.com
on 2 Aug 2012 at 1:45
If you're seeing different result on the command line and in MercurialEclipse
then right click on the project and select "Team -> Refresh Status".
MercurialEclipse doesn't automatically refresh its status when doing things
outside of Eclipse.
Original comment by johnpeb@gmail.com
on 2 Aug 2012 at 2:36
That doesn't work either.
What my problem is:
- We have an external tool that generates source from some resource files (text
based resource files). These resource files are committed to the repository so
we can regenerate the sources during build.
- Due to a change in the external tool it generates now files completely
lowercase. Before it contained some uppercase characters (as said before).
- We cannot control the change of the generated file name case.
- We have old projects that contains uppercase characters and are committed to
the repository. When continuing development it need to track the files.
What happens now:
- File is tracked and in sync with repository.
- Resource file is changed with external tool and after save the filename is
completely lowercase.
- When running "hg status" on the command line (or "Add Files" from the
turtoiseHG menu) it shows that the file is changed (marked with a
questionmark). So the file is still tracked.
- In eclipse the icon repository_rep disappeared from the file icon.
- This is not changed with a workspace refresh, project refresh, folder
refresh, "Team >> Refresh Status", eclipse restart, project close/open (this
also refreshes the MercurialEclipse status).
- When running commit from the eclipse plugin the file doesn't show in the
affected files (not as changed and also not as new).
- It is not possible to add or commit the file anymore with the plugin.
- From inside eclipse with MercurialEclipse it's completely not noticeable that
the file is not tracked anymore and the changes are not stored in the
repository.
Original comment by ronald.k...@kvernelandgroup.com
on 2 Aug 2012 at 5:30
Are you sure the only difference is the case of the name? After changing only
the case of a file name hg 2.2 command line status reports the file as clean.
This should be the case in all other versions of mercurial on windows, unless
there is a bug in older versions.
Are you sure the command line and hge are using the same version of hg?
If there are other differences between hg command line and mercurial eclipse
then it is because of Team Ignored Resources or because its an otherwise
strange resource.
Regardless of MercurialEclipse you have a tricky situation if you need the
filenames to be the new case because Mercurial doesn't support renames
differing only in case on operating systems with case insensitive file systems.
You need to do something like I suggested in comment 3.
Original comment by johnpeb@gmail.com
on 2 Aug 2012 at 5:59
Yes, I'm sure that the only difference is the case of the name.
I tested it with only renaming the file in the windows explorer.
I have only one Mercurial version installed on my system (2.2.1). I can try to
upgrade to the latest version.
When I only change the case of the filename hg status doesn't show the file (or
at least not with the default options. When providing -c it shows the file as
clean).
But directly the repository_rep icon disappears from the file in
MercurialEclipse. So it lost track already there while the file is still marked
as Clean.
I know that the situation is tricky, and for me it's not a problem because I
use the combination of MercurialEclipse and the Commandline a lot.
But we have a lot of developers and a large project and codebase. And most of
them are only using MercurialEclipse.
Original comment by ronald.k...@kvernelandgroup.com
on 2 Aug 2012 at 6:13
The problem has to do with the case inconsistency of the windows file system.
See
http://hgbook.red-bean.com/read/file-names-and-pattern-matching.html#sec:names:c
ase for the information.
The problem is that Mercurial on windows is "Case preserving" and the
MercurialEclipse plugin is (as far as I can see) "Case sensitive".
So when running "hg status" on a repository it shows that the file "test.c" is
Clean, but in fact it's "Test.c". In MercurialEclipse the file cannot be found
so it doesn't show the "repository_rep" icon on the file.
The same with adding. When running "hg add -n" the file doesn't show up in the
list, so it will not be seen as "new" by the MercurialEclipse plugin.
Original comment by ronald.k...@kvernelandgroup.com
on 3 Aug 2012 at 6:04
Thanks for the explanation. It's definitely a bug.
Original comment by johnpeb@gmail.com
on 4 Aug 2012 at 3:30
Hi,
is there any progress on this item?
Original comment by ronald.k...@kvernelandgroup.com
on 25 Feb 2013 at 4:48
Original issue reported on code.google.com by
ronald.k...@kvernelandgroup.com
on 2 Aug 2012 at 6:49