I get this error in realtion to my [username].mode1v3 package file:
Error: 155015 (A conflict in the
working copy obstructs the current
operation) Description: Commit failed
(details follow):
I can do a compare from the SCM results menu on this file. Doing so reveals 102 conflicts (differences) between my local copy and the latest version in the repository. Problem is I don't understand what this file relates to or how to fix it. Differences occur in the file under keys like
PBXSmartGroupTreeModuleColumnWidthsKey
which I have no idea about.
I am the only one working on this project. How is it possible to resolve a conflict such as this?
Many thanks.
Sounds like you're probably working on two computers?
Any conflicts that happen in that file can safely be ignored - just tell your SCM to accept your local version. It's one of the files Xcode uses to keep track of your project state within the IDE.
I'd recommend taking it out of source control and telling your SCM system to ignore it.
This file contains your personal Xcode settings (like window positions and so on). It should not be under version control at all.
Related
I opened VSCode and was presented with a notification that there was a conflict between two versions of a file. I followed the prompts and got a side-by-side comparison of two versions. I clicked the button that accepts the newer version, believing that VSCode had correctly inferred which version was newer. It had not, and I lost a significant number of changes to the file. Is there a cached copy of the other version anywhere?
Thank you!
ps - I seem to have failed to actually commit the changes in git as well. Not sure how that happened.
After searching through the VSCode appdata, I concluded that it wasn't likely that there was a copy. I found a copy of the bytecode (.pyc file) and used uncompyle6 to get an approximate copy of the version of the .py file I needed to recover. Was able to manually merge from there.
I was flummoxed by this one too. The answer is that you can restore the old version by hitting undo until before the change was made.
I have two configurations:
ea-sparx
CVS - Architecture
Both point to the same working copy path. It seems that I have checked out an existing repository under one configuration (CVS - Architecture), but I have made changes and checked them in under the other configuration (ea-sparx).
Question: How can I move all my changes to the other configuration?
In the first place, Not sure how you changed the configuration of a controlled package. But if both are pointing to same working copy, Get All Latest should get you the latest. If you still have problems checking in / checking out, that could be due to due to out of synch, You can try "Resynch status with VC provider" for that package.
I don't know what models you have created, but UML models are saved as XML-files. Those XML-files contains tags looking like
<UML:TaggedValue tag="packageFlags" value="Recurse=0;VCCFG=CVS - Architecture;"/>
or
<UML:TaggedValue tag="packageFlags" value="Recurse=0;VCCFG=ea-sparx;"/>
A possible solution:
edit the XML-files manually: change ea-sparx to CVS - Architecture in your XML files
remove the ea-sparx configuration from Enterprise Architect
Get All Latest
I am evaluating PostSharp for a new project but cannot seem to get past the following error when I first build the project after changes:
Cannot copy file "C:\SourcePath\Output\Debug\MyApp.vshost.exe to
obj\Debug\Before-PostSharp\MyApp.vshost.exe: the file is locked by
process(es):MYAPP.VSHOST (8064)
The error only occurs in the first build attempt. If I immediately re-build, the error does not occur. I can only guess this is because the project isn't actually being rebuilt the second time.
I've read a few posts in the SharpCrafters forum that indicate this problem existed prior to v2.1 but was reportedly fixed. I am using v2.1.6.14 from NuGet (in VS 2010) and getting this error for every project I reference PostSharp. It is certainly not reasonable to require 2 builds every time, so I'm looking for a possible solution. I'm really pleased with what I've seen thus far but will have to go another direction if that can't be resolved.
UPDATE
Per Gael's request, I generated the diagnostic build log and sent it to him and it looks like he was able to resolve the problem in the latest release (2.1.6.14).
I believe part (or all) of the issue may be due to the fact that the build output for all of my projects is set to a common location (i.e. not the /bin/debug folder under each project). This is because we are using a MEF DirectoryCatalog which will discover Imports and Exports contained in the assemblies located in the output path. The PostSharp.targets file has the vshost.exe file excluded from the copy operation but only when it shares the name of the output assembly. In my case, the vshost.exe file has a different name and was, therefore, not being excluded.
The issue has been re-fixed in PostSharp 2.1.6.15.
I get the following error when trying to "update" my eclipse project :
failed due to an internal error (took 0:00.337)
Error: Problem writing resource
'/sspaceex/src/PLWL_implementations/CVS/Template'.
A resource already exists on disk
'/home/ray/workspace2/sspaceex/src/PLWL_implementations/CVS/Template'.
Error: A resource already exists on disk
'/home/ray/workspace2/sspaceex/src/PLWL_implementations/CVS/Template'.
***
Any idea why this error and how to get rid of this?
Error: Problem writing resource
'/sspaceex/src/PLWL_implementations/CVS/Template'.
A resource already exists on disk
'/home/ray/workspace2/sspaceex/src/PLWL_implementations/CVS/Template'
Try to close as many active process as possible to check if another application does not "block" that resource.
As Narayan suggests in the comments, if it exists, check if you can delete it manually (outside eclipse) before attempting another refresh in eclipse.
The server reported an error while performing the "cvs update" command:
sspaceex: cvs update: nothing known about `doxygen/htmlclasscontinuous__sets_1_1sequence__transform__coll__graph.md5'
That should mean that the resource is removed from the file system, but not removed from CVS (i.e. on CVS server, an entry exists for this resource).
That is consistent with the failed update which was unable to write in that directory.
Doh,
I had to updated project configuration. This created the folder that Eclipse didn't like. Then close the project. Then reopen it. Then update project configuration again. Do a little dance and song, and violla!
In that order.
Cheers,
M
I hit this issue due to resource wildcard exclusions in my project. My project and CVS repository contains numerous file types that I never edit (for example, *.asm assembly files). To reduce workspace view clutter and to make searches faster, I had excluded these file types from my project when I had originally created it.
From what I can tell, this causes Eclipse/CVS to think it needs to add all these "missing" files to my project when I attempt to do an update (as evident in the incoming changes in the Team Synchronizing view). When I removed the resource filter from my project, the update process was able to complete.
This is sort of a pain because I have to choose between the two, or I have to keep adding and removing these filters based on when I want to perform an update.
Eclipse is confused because a file exists that shouldn't be there. Close the project and synchronize again and it should go away.
[EDIT] cvs update: nothing known about '...' means that Eclipse believes that this file is under CVS control and the CVS server says "I have no idea what you're talking about".
Reasons can be that your CVS server got corrupted, somehow, of that the contents of the files CVS/Entries and CVS/Entries.Extra is wrong (Eclipse records what is under CVS control in these files).
I suggest that you delete the project in Eclipse (don't check "Also delete files on disk"), then rename the project on disk to something else, and do a clean checkout.
After the checkout, you can copy any changes you make back (but don't copy the CVS directories or anything inside of them!)
I had this same issue. For me, it had to do with the fact that eclipse was out of sync with the file system. I just had to refresh the project (select the project, then hit F5) and the "update" was okay.
I had to manually delete the resource, then refresh the project, then update, and it worked.
Note: I have Build Automatically turned off, it might be that the refresh will cause an automatic rebuild that will create the resource again, so make sure there is no build done between deleting, refreshing, and updating.
After doing a fresh checkout using Subversive, some of the directories retrieved because of svn:external properties are showing up as obstructed. However not all of them are. A command-line use of "svn status" properly shows all the directories as externals with no obstructions.
Why is this happening?
This does looks like this thread
We checked the situation and we had found that the problem can happen in case if working copy is locked by external process in time of update.
For example, the process TSVNCache that related to TortoiseSVN time-to-time produces conflicts with working copy access and JavaSVN library cannot complete working copy modification in correct way. As result working copy goes into "Obstructed" state, i.e. it is damaged.
The same diagnosis related to any process which locks working copy in time of working copy meta-data modification. (We found same behavior for MS Visual Studio 2005 Express Edition, but I don't know why the Studio locks WC?)
So be sure to make the checkout with the least possible number of application running.
Another source of conflict could be:
The SVN 1.4.x-compatible clients are automatically converts working copy into 1.4.x-compatible format. At the current moment Subversive Default client is incompatible with SVN 1.4.x working copy format.
So, if you performed any modification of the working copy using command line SVN client in your case you will get "Obstructed" state indicated over the resources in the workspace tree.
In order to resolve the problem I will propose you to switch SVN client option and select SVN Kit 1.1.0-based client or Native JavaHL 1.4.2 client.
Next, if resources already decorated as "Obstructed", please close and then open again corresponding projects or simply restart Eclipse IDE in order to reload SVN meta-information cache.
Now : the exact version may not be the same for you, but that is another lead to check.