I was working on my project on JDeveloper since several days, and today I wanted to create a new project related to this one so I imported all the files, but finally i decided to remove them so i selected them and clicked suppress.
I thought that would just remove them from the new project but it did erase all my classes.
Do you have any way in order to retrieve those files?
It can be related to Windows or to Oracle I don't have any clue to wich thing i have to do in order to recover those lost files.
I found the solution for those who could expect the same issue :
Right click on application source then Restore from local History.
It saved my day, i hope it'll save yours !
A while back we renamed the main folder where our project source code is, and for some reason, TFS represents this as a discontinuity in the history:
This is kind of annoying, because whenever I need to look at something from before the rename, I have to keep expanding the child nodes until I can continue to search. I've also just discovered that when enumerating through the history using the API (via VersionControlServer.QueryHistory), it stops at the rename (changeset 1172).
This is getting very annoying. Is there any way to fix this break in the history? Failing that, is there a way to get QueryHistory to return the full history, including before the rename?
For the api question:
I vaguely remember how history was rewritten in Visual Studio 2010. I also peaked at MS.TF.VC.Controls.dll in ilspy, I hope Chad will forgive me ;) What works for sure for files renames (I would hope for parent renames as well) is to use QueryMergesExtended and specify to include sourceRenames. A rename in TFS 2010 and later is branch and delete, so you can find source of every rename, by following where it was branched/merged from. It will definitely require some coding on your part.
For the UI question (I know I'm backwards here) what exactly are you searching? Comment? Filename? Specific content change?
It appears that there's no way to get the UI to do what I want. But on the API side I realized that the break in the history was actually caused by the way I was searching:
Dim changeSets = vcs.QueryHistory("$/ProjectWithCurrentName", RecursionType.Full)
This wasn't finding the changesets before the rename because I'm searching by name and the name is different. So now I just run this twice, once with the new name and once with the old, and merge the results.
I am using TFS 2012 express. When i try to use get latest version I get so many conflicts(more than 250). When I compare it i found that almost most of the conflicts are due to Case differences. Some times i do i get valid conflicts and which can be manipulated using merge tool. But comparing this lot number of conflicts(more than 250) is very difficult to me. For example in below image you can see changes like MsfgTemp and MSFgtemp(this kind of case differences) . I do get lot of this kind of differences(one more i got is Val and val) . No one has made any changes to those lines actually. But still conflicts are shown. Why this kind of conflicts I get during get latest version? How to solve this?
EDIT:
I have found some thing interesting after some research on it. I did several steps to find reason for it. When i was doing it no other user in my team was using TFS or changing anything.
The server has MsfgTemp(in so many lines of code).
I created new workspace and without changing anything compared with server version. As expected no difference found .
Now I changed some lines of code and saved the project.
Now when I see difference I found lot of differences. All changes are like MsfgTemp and MSFgtemp. Another was val and Val .
So it is sure that the reason is not some one changed or anything else. While saving project something causes these changes. My project is of VB6. I edit projects using Microsoft Visual basic 6.0 only.
So now what may be the reason for this kind of difference and how it can be solved?
You should check the TFS file history or use the annotate option to see who changed those lines and when they were changed.
Since TFS only stores the files it doesn't change the contents you should first find out who checked in the changes and that will lead you to the how and why it changed.
NOTE: from looking at the little bit of code you posted in the example the same variable name is used two lines above in both files without conflict.
TempVar = MSFgtemp.TextMatrix(i, TaxDeductedCol)
the conflict your are noticing just two lines later is for a very similarly named variable but I believe this one is different since it is declared inside the loop, so this might be a bug fix with a poorly named temp variable inside the loop...
TempVar = MsfgTemp.TextMatrix(i, ArrAddColNum(k))
Everytime I build my solution the setup project's .vdproj file always gets modified.
This has always annoyed me, but especially so at the moment since I am making some big changes and upgrading some projects and I am finding it very frustrating trying to figure out if the setup project actually has any changes which I should be concerned about.
Looking at the svn diff it just seems to modify guids and reorder sections for some reason. Is there anyway I can stop it doing this, or can someone explain why it feels the need to keep doing this when seemingly nothing has changed?
Thanks
I hope this qualifies as programming related since it involves how to structure a project.
Because I've always used the web site model with VS.net I never had solution and project files and putting everything into source control worked great. I knew that everything I had in my web site directory was all I needed for the web site.
Now I'm using asp.net MVC and it only has a project model so now I have these solution and project files. If I work on it alone it's fine but once other people start to add/delete files from the project our solution file gets messed up and people end up having to grab the latest solution file, see what got changed and then add back/remove their files and check in the solution file again. It's become sort of a problem because sometimes people don't realize the solution file was changed, they make other changes and then when they check in everything other people do an update on their files they find that their files are gone from the project (although still physically on disk).
Is this normal? Is there a way to structure a project so that we don't need to check in solution and project files?
Your developers are not using TFS correctly. You should have multiple check-outs turned on, and everyone needs to be careful to merge their changes correctly when checking in. TFS will prompt you to do this, and accepting the defaults is nearly always the right thing to do.
It's not uncommon to have one or two developers who never get it, and you might have to help them now and then. But every programmer who works on a team needs to learn how to use source control tools correctly. If they can't manage that, they shouldn't be writing software.
[edit] It occurs to me that you might run into these problems if you check in the *.sln file directly, rather than choosing to "Add Solution to Source Control".
I don't think it's normal - what are you using for source control? It sounds like developers aren't respecting changes that others a making - checking in without merging first.
I know that early on in a project, when lots of files are being added & deleted, it can be a problem to keep up - you need to check out the project file, add your files, then check in the new file & project so other developers can also update it. You'll probably have multiple project files in a solution - perhaps one interim solution would be to have one "holding" project for each developer, then clean them up periodically - though these types of temporary fixes do have a tendency to become permanent.
I don't know of a way to set up a project file that's not in source control, though I suppose you could create a script that would generate them.
Having been through this, the key is respect & good communication between the developers.
This tends to happen with TFS multiple check outs. It can be hard to grasp coming from VSS to TFS as VSS allowed one person to check a file out at one time. Auto-merge should work most of the time for you but a couple of rules should ease the pain:
Check in early and often (if you add remove or rename a file check it in straight away even if it is a blank holder)
Before you check in do a get latest, this will ask you to resolve conflicts locally
Try to get continuous integration set up so that developers always know the state of the buidl and whether it is OK to check in\out.
We had a bit fo pain at the start of our current project but it soon settled down when we followed the rules above.
Personally, I think making changes to project and solution files requires discipline and clear (well understood) rules throughout your development team. These files (.sln, .*proj) are the bottlenecks of your project, and any errors or inconsistencies can cost you in team downtime. Changes need to be well thought out, planned and then executed.
They must be secured by source control (which you're already using, excellent) and your team members should work on the basis of only making the changes they need, and not leaving project or solution files checked out for an extended period.
If you are allowing multiple (shared) checkouts, this could become problematic in terms of overwriting another user's changes. Depending on your source control mechanism, people may be required to manually merge changes. Personally, I'd ask people to negotiate their project/solution changes with each other over merging (this can't always be achieved).
A third option if you are using TFS is the shelve feature. If someone needs to make changes locally, they can shelve the changes and merge later.
Lastly, another strategy is to try to architect your solution to be as modularized as possible - so people are distributed, working on separate projects and do not (ideally) have to overlap on too many common areas.
I'm not sure if you are using TFS, as people have mentioned, but if you are (or if you are using source control with similar capabilities) you can set it such that sln and csproj files are exclusive lockouts and are not able to be merged.
We have done this with quite large teams and while it causes some initial issues as people get used to it in the long run it has resolved many issues that were previously causing problems. Essentially you trade longer term merge issues/complexity for short term compile/checkin issues which we have found to be a good trade off.
Once you have set it to forced exclusive checkout and no merge you then get your dev teams used to the fact they should keep locks on the sln and proj files for as shorter time as possible.
Always check them in.
Always check out latest (merge if possible), make sure your change is there, before checking in a new version.
If your source control doesn't require a special action to check in from an old version, GET A DIFFERENT SOURCE CONTROL.