I have two streams :
-dev - it is used by all developers and whole changes were marged to this stream
-netmajor - it is my own private stream
When I have few changes I Submit them to my private depot and then I see on Dashboard information "Copy to dev (x changes)"
When I Submit this changes from my stream to Changelist on dev depot I see that some files were submit unnecessary, so I revert them. After this I see on my private depot Dashboard information "Copy to dev".
Were files reverted to private depot?
Why I can not see them on Pending tab? How can I revert them from private depot like these changes never exist?
When I Submit changes to Depot, they cannot be removed back to workspace?
Roll back the changes in your private stream -- you can pick a point in time (e.g. a changelist) you want to roll everything back to, or you can pick individual changelists that you want to back out while leaving other (possibly later) changelists intact. This is done with either the "roll back" or "back out" command in P4V, or by "p4 sync" and "p4 edit" at the command line.
There's an in-depth video tutorial here: http://www.perforce.com/resources/tutorials/rolling-back-backing-out-changes
Related
I have commonly copied a folder / contents and added a date to that copy name.
With VS2019, I see "The action can't he completed because the file is open in ServiceHub.Host.x86".
How do I get rid of this message? (I don't want to go back close the project, copy the folder / contents, then re-open it.) I don't use Service Hub (whatever that is)
A quote from a VS agent:
"I test in my side with different kinds of solution/projects and I find that it seems when I use C++ Console Application, it will work and successfully copy and paste/modify. But when I use C# Console Application the dialog window stops me."
"I strongly recommend you to report this condition to product team for further improving or maybe suggest a feature to add an option to disable this auto-locking feature."
"Help -> Send Feedback -> Report a Problem… is appropriate."
SVN repository keeps the log messages as properties attached to each revision. these properties are kept in db/revprops folder of repository with same numbering as revision. I needed to change format of the log messages and include some extra information. Format of the prop files (at least for version 7 uncompressed) is just key value in text format. I wrote a small program to do this and successfully edited the log messages.
Running SVN Log verifies the command line and shows updated log messages
Problem
Opening TortoiseSVN in dev computers does not show the updated messages in list; however if developer right click on the revision item in list and select Edit log message the edited message will show up. Even checkout of whole repository to new folder still shows the old message.
Question
Above observation makes me believe that TortoiseSVN somehow caches the log messages in client computers. Where is this information stored?
Yes, TortoiseSVN caches the log messages and changed paths. You should be able to clear the cache via TortoiseSVN Settings | Log Caching | Cached Repositories.
Read TortoiseSVN Manual | Log Caching & Cached Repositories for further information.
NOTE: Log caching is a very helpful feature. Don't disable it and be careful when you enter log messages.
On the SVN setting go to log caching, and under tab 'global setting' untick the checkbox 'enable log caching'.
click 'ok' .
it shall solve your problem
I have a quite weird problem here with UCM-ClearCase.
A user tried to deliver from his dev-stream to the int-stream of the project. For some reason he decided that he needed to cancel the delivery and executed "deliver -cancel". According to him this did not work the first time (although he does not remember the error message) but the second time he issued the command the delivery was actually canceled.
The problem now is that he has a checkout in his int-view (!) that does not have an activity attached to it. The activity of the delivery was deleted (obviously during the cancellation of the delivery). If he tries to undo the checkout in the int-stream (by using "unco") ClearCase outputs a warning that he needs to set an activity and a view context in order to undo the checkout. Setting some activity (and a view context) is no good, the same error message appears.
EDIT:
The exact error message given by ClearCase is:
cleartool: Error: To operate on UCM branch, must be set to an activity and a UCM view.
cleartool: Error: Unable to cancel checkout for "PathToFolder".
The checked out element is only a folder and no other elements (neither files nor folders) are checked out
END_OF_EDIT
Creating a new activity in order to attach it to the checkout did not help either as I did not find a command to attach an activity to a already checked out folder.
According to IBM we could remove the view and all its references and then re-create it which should solve the issue of the checkout.
I am kind of hesitant to do so without being sure that there is no other way to handle the situation (especially as the above-mentioned link states that there might be cases when removing the view does not really help). Is anyone aware of a different solution for this kind of situation?
Best Regards
I confirm that to remove all checkouts associated with a specific vob and view is
cleartool rmview -force -uuid (uuid_of_the_view) -vob \aVob
See "unable to perform delivery on clearcase because of checked out file in snapshot view?"
Simply make sure the user has no other checked out files.
I am trying to rebase a stream with a particular view but it is not letting me to rebase saying "change sets are not empty" while rebasing from windows GUI but if I look at the sepecific rebase activity which is set to rebase, there is no change set on it. And when I tried to rebase from cmd, it gives me an error saying "rebase doesn't match the specified view and ....is not the view where you have started the operation". I don't remember that I have started the rebase opeartion in aother view.
What is best way to deal with it?
PS: I can't cancel or resume or complete the rebase opeartion here.
A cleartool rebase -status -stream StreamBeingRebased#\apvob should give you the name of the view currently used.
If that view doesn't exist anymore, and if you are in ClearCase 7.1+, you can try a:
cleartool rebase -resume -reset -to newviewtag
That would try and resume the rebase using a new view.
I would recommend for that new view to be a dynamic one, instead of a snapshot one: it is quicker to start and succeed/fail, and you can do multiple tests without waiting for the view to update itself (update being done only in a snapshot view).
First of all, I'm not using Core Data, I'm using SQLite only.
I save the data in the table and then query them by opening the app and looking at the data using SQLiteStudio. I even create a LOG to check that the data is saved, and yes, it is saved.
But when I STOP and run the simulator again to consult, there is no more data!
Is Xcode overwriting the database every time? Or is something else happening that is outside my limited knowledge?
Without knowing more about how your application is setup, how you've got your app configured to build, or how it operates on the SQLite DB file in question I'll only be able to offer some pointers in things you can go check out about your code and build configuration that may be the source of your phantom deletions. Of course, if you have other info to provide, I'd be happy to edit my answer!
Case 1: 'Create DB' always running?
One thing that may be tripping your app up is what happens leading up to the decision to create a new SQLite DB file or look/open an existing file. If the code creating an empty DB is always running, then each time your app starts, your old DB file is getting overwritten with a blank DB.
Case 2: Using a 'starter' or 'template' empty database?
Sometimes developers may provide a blank database that contains the initial database schema (the general tables and structure) as well as some default or sample data. If your app does this, perhaps the logic leading up to the decision to apply that default database is accidentally always being triggered? If so, use of NSUserDefaults to record a boolean indicating the DB was successfully created may be an avenue to use to skip past the 'Load my starter DB' code. Alternatively, you could check for the existence of your DB file, or see if the contents of a specific table are different from the template data, etc.
Case 3: Different Behavior between 'Build & Run' vs. 'Run Without Building'
There's a not-so-well-known option in the Product > Perform Action menu labelled 'Run without Building' that will essentially kickoff another Debug session using the version of the application you just finished running in the Simulator or on Device. When you use this option do you see any different behavior with your database or is it still blank?
Case 4: Different Behavior when run directly in Simulator outside of an Xcode debugging session?
Part of the 'Run' operation is a build phase which may trigger the 'Copy Resources' phase even if your app hasn't changed since the last execution (as you suggest is the case in your question). If you are providing a stock 'default' or 'template' DB file and your app is simply opening and editing that 'template' during the first execution of your app, then Xcode may be replacing it with a clean copy on the subsequent 'Run' operations where 'Copy Resources' is happening. A way to test this avenue:
Build and Run your app to the simulator using Xcode like normal.
Perform some operations that would result in the creation or editing of data in your app's database.
Click the stop button in Xcode to return to the Simulator home screen.
Double-click the home button on the simulator (or if there is no home button, press CMD+SHIFT+H twice to bring up the multitasking bar and force-quit out of your application.
Check and see if your DB file has data in it.
If no data, then there is an issue persisting your changes into the database and we need to get that problem solved first. Otherwise:
Relaunch your app directly from iOS Simulator and perform different operations that would result in more or different changes to the database.
Click on the home button to return to the iOS Home Screen.
Force-quit your appellation as was done in Step 4.
Check and see if your DB file data has changed (but still has data) or has blanked out.
Finally, make sure you are following Apple's guidance about where to store user-data, if you are inadvertently storing something in an incorrect file path doesn't typically result in blanking of data, it may be prohibiting writing of data which could be interpreted as your data getting overwritten especially if you are interrogating it while it still is residing in an in-memory process. There's some really useful guidance about file paths in the Table 1-1: (http://developer.apple.com/library/ios/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/FileSystemOverview/FileSystemOverview.html)
Locating your Simulator App on your Mac's Hard Drive
To be thorough (and you may already know about this!), iOS Simulator applications are stored on your Mac's hard drive just like other files on your machine. Their organization mimics that of a physical iOS device. To get to your App and its data:
Open a new Finder window.
Press CMD+SHIFT+G or choose 'Go to Folder' from the 'Go' menu.
Paste the following into the 'Go to Folder' box then click 'Go': ~/Library/Application Support/iPhone Simulator/
Select the folder that matches the iOS version of the simulator you built to.
Click on Appications.
You'll then be presented with zero or more folders, each folder that appears will have a string of digits separated by hyphens. Navigate through this list until you find the one containing your app. You can then browse, and copy data out of this folder to somewhere to be examined by other tools on your Mac.