If I check-in file to TFS repository without getting the latest version (i.e, without merging the changes on my side first) then, is one of the version bound to loose? Let us assume v1 is the version on TFS that I forgot to get and merge before checking in, and assume v2 be the version that I checked in. Suppose v1 exists on another machine, can I go ahead re check-in v1 without getting the latest version on the second machine, and redo get-latest and merge on primary machine to have everything recover? What are my options to minimize the loss? What happens if I did not have the second machine with v1? Are there any mechanism in TFS that prevent me from checking in my version without getting the latest from the TFS first?
Assuming someone have checked in v1 to TFS on another machine during you work on your machine, then you may get conflicts warning. The conflicts maybe automatically resolved, maybe request you resolve manually.
Related
General: I develop an Azure DevOps extension with tasks and pipeline decorators. Testing on local Azure DevOps Server instance. Extension loaded through manage extensions from local hard drive. Let's say that I installed the extension first time with version 1.0.0 and a node_modules dependency "3rdPartyDep" with version 2.0.0, which has transitive dependencies with vulnerabilities.
Scenario:
Upgrade "3rdPartyDep" to version 3.0.0 with fixed vulnerabilities. Build new version of my extension, say 1.0.1. Create the .vsix, update the extension in the Azure DevOps Server.
Run a pipeline, which fails because I did not check the "3rdPartyDep" changes and there are breaking changes and the extension fails to run.
Rollback the "3rdPartyDep" library to 2.0.0 because I have no time now to check what is broken in there right now as I have other things to debug and implement, repackage the extension, increase version to 1.0.2, update extension in Azure DevOps Server.
Run the pipeline. It fails with the same exception, as if I didn't rollback. I look into the agent taks folder and I see that the node_modules with the "3rdPartyDep" library is pointing to 3.0.0, which is wrong because I rolled back the version.
I open the generated .vsix archive and check that the node_modules inside contains the correct 2.0.0 version, so no problems of packaging or building from my side.
I make a conclusion that Azure DevOps stores somewhere a cached version of the extension with the node_modules including the wrong version of the "3rdPartyDep". I search that cache folder over internet to find out where it is, and I also search with a search tool all my machine, including words in file. Nowhere to be found. There is no location on my machine with such node_modules containing the 3.0.0 version. It might be stored in some encrypted DB?
I uninstall completely the extension, and install it back. I see that Azure DevOps has a history for the extension, and the cache is not cleared. Any pipeline fails, even if my .vsix does not contain this dependency.
I'm stuck.
Questions:
Where extensions are actually cached inside Azure DevOps Server?
Why updating, uninstalling and installing does not fix the problem?
Is there any way to fix this? What can I do? I do not want to reinstall the server completely. Moreover, this raises concerns about how node_modules are managed and cached and what happens at the clients and the cloud.
You could try the following items:
Try to clean the browser cache, and check whether you have increase the version number in the task.json.
Try to perform Delete task -- Save definition -- add task again process.
Delete Azure DevOps Server cache, which can be followed in this link.
Uninstall the extension from CollectionSettings, remove the extension from local Manage Extensions. Then upload again the extension and install it in the collection.
TLDR; My version of the SVN-repo differs from my teamates. Even though the repo-UUID is identical and we are using the same branch (exactly the same repo-links).
My SVN was working fine before i went home for vacation.
I came back, updated my repo, commit some changes. Everything seemed to work fine. But it turns out that my team cannot see my commits and when updating - my commit seems to be the latest one. Looking through their clients, the revision-numbers i have checked in collide with other commits.
Im using Ubuntu 18.04.1 LTS -
svn, version 1.9.7 (r1800392)
I tried removing the repository and checking it out (removing the .svn dir as well) - and when i do, my latest commit is HEAD. (Instead of the real HEAD which has a revision number way higher).
When i browse the repo from the web-browser, my commit is HEAD.
When they browse the very same link - their commit is HEAD.
Restarting computer does nothing. Reinstalling subversion (removing ~/.subversion) did nothing.
We tried checking out the repo using different user - still my commit is HEAD.
If i use my account on different machine, it works fine.
The repo-UUID is the same for me and my colleagues.
Im thinking this might be some kind of cache issue, but what cache is both used for svn and browser?
Additional thoughts:
I am also using a VPN to access the corporate network. Could there be a cache there? But the SVN-traffic is using TLS, what could possibly cache TLS-data?
#Simion pointed out that it might be a good idea to make sure the hostname of the Repo resolves in the same IP.
Turns out that was the problem. The CM-Center had moved the repo to another server (and for unknown reasons kept a copy of the repo on the old server - which caused all this confusion) and the Infra department had changed the IP of the repo hostname.
Flusing my local DNS-cache fixed the problem!
I got quite few items are list on my Pending changes Resolve conflicts,
however, when I undo all my pending changes,
those conflicts are still there, and when I try to resolve them manully, it said my local version is 0, and my local change is indetical with the server change, when I try to take server version
it pop up the error string must have a least one character, Prameter name: item,
My TFS is TFS2013 RTM
vs version bothe VS2013 and VS2012
thanks any suggestion or advice,
kind regards
Undo all Pending Changes, make sure there are no pending changes under the Excluded Items section, then do a Get Latest. That should bring your workspace up to date, and there should be no conflicts.
I experienced something similar in VS2015. No changes in my workspace but there is a conflict that can't be cleared. As best I can tell there is an entry in an internal conflict table.
I used the tf command to clear conflicts. Don't do this to clear a real conflict.
command documentation:
https://msdn.microsoft.com/en-us/library/6yw3tcdy.aspx
Open Developer Command Prompt
Change directory to conflict location: cd <path/to/conflict>
To resolve one conflict, replace .\ConflictFile.txt with your file name:
tf resolve .\ConflictFile.txt \auto:DeleteConflict
or
To resolve all conflicts: tf resolve \auto:DeleteConflict
I am facing a problem with TortoiseSVN (my client version is 1.6.16 and the SVNversion is 1.4.6.28521).
The projectA project has the classical architecture, with three folder: trunk, branches and tags.
I have rights to Read and Write from a projectA folders (tags,branches and trunk).
While working in the trunk, there is no issue, everything works fine. The only problem is that when a release time comes (or branching time comes), and I want to create a tag (a branch), I want to use the TortoiseSVN dialog "branch/tag". Then I choose the origin from the trunk or the revision o nthe trunk i need, and choose the "To URL" like "http://..../projectA/tags/v2.0".
After clicking "OK", it will let me know that the access to "http://...../projectA/" is forbidden.
The only solution right now, is to checkout the "projectA/tags" folder to a local folder. Then in this "projectA/tags" folder I will create one new folder with the name of the tag I want to create, and I am able to commit it without any problem.
I don't want to manually create the folder of the tag/branch like this, andwould rather like to use the "branch/tag" feature of TortoiseSVN.
Anyone has an idea about this issue ?
There is a recommendation in Subversion (at least on Windows with TortoiseSVN) to use the same major version as the server. You are allowed to ignore that recommendation, and most of the time, it does not hurt, but here you may have a case where it makes a difference. You should at least check if
the server could be upgraded to 1.6.x XOR
the client (your installation) could be downgraded to 1.4.x
However, your client will ( in the second case ) no longer work with your checkout directories. Branching has changed a lot from version 1.4.x to 1.6.x, so you will face a hard time if you have to use a 1.6.x client with a 1.4.x server.
I have an app that I have been working on and I did a bunch of changes and then realized later I should have been adding versioning to the Core Data model. So I'm trying to go back and do that now.
Basic information:
I think everything I've done would fall under the lightweight migration feature.
I'm using git
I already have the app in user's hands
My question is: what is the easiest way to do this?
Since I'm using git, could I simply checkout the data model from when I submitted it to apple, create a new version for it, and add my changes? My main fear with this idea is that my project.pbxproj file would be incorrect. Would this an issue? Is there a way to get around this?
IF I could do this, would I need to recreate my class files or would that be ok (assuming I get it back to being identical to what I currently have).
IF I CAN'T do this, then what can I do? If its a matter of starting from the last version I pushed to Apple and applying changes I guess I should look into doing it with git rebase, right?
This has nothing to do with git.
You need to create a new version of your app, provide the new data model, set it for lightweight migration and then release it as an update. Core Data will basically assume that any model without version info is version zero and attempt a migration to the new version.
When the user downloads the update, the automatic migration will trigger the first time the app runs.
Creating a new version means nothing more than changing the version number in the project info. When submitted, that will trigger the upgrade and the migration.