For example, there is a file in my Perforce depot at //my_depot/my_stream/my_folder/file.txt, which has a long revision history. Due to a refactor, the file is then copied (integrated) to //my_depot/different_stream/another_folder/file.txt. This keeps the revision history by keeping a reference to the original file as its "branch from" integration source.
What happens if the original location of the file (in this case, the entire my_stream stream) is deleted? Does the file's revision history remain accessible from the P4 server?
When a file is "deleted" in Perforce, a new revision with the action delete is submitted on top of the existing revisions. Old revisions remain exactly where they are, old integration history referencing those revisions remains valid, et cetera.
When a stream is deleted, the stream spec is gone, but the depot files that were part of the stream aren't affected in any way, so again, history remains accessible. You can still reference the files by their depot path, and old integration history still points to them.
When a file is obliterated, its history is gone forever. Only an admin can obliterate files, and this is something that should only be done when history is no longer important (or never at all).
Related
I have conentstore configured in below content store location.
D:\alfresco-content-services\alf_data\contentstore**2019**
I want to delete above shown 2019 folder under conentstore. I dont need 2019 anymore. Basically purging .
If i delete files above folder ,will it clean-up the metadata and indexes also ?
or will it corrupt my respository ? Whats the best way to achive mass deletion , which will delete references in database also without corrupting repo ?
Thanks & Regards
Brijesh
If you delete any folder from the content store, it will not affect the database (and hence the indexes) in any way. You will end up with nodes referencing .bin files that do not exist anymore, though.
Note, if that folder is the first year in your content store, then it also contains some files used by Alfresco to determine if the content store matches the database. Depending on this, if you delete the folder - you will mess up Alfresco (repository will not start if it does not find those files).
Mass deletion in general is tricky, I'd suggest using Bulk Import Tool's delete web script that does this as fast as possible (avoids audit logs, recycle bin, etc).
I have enabled OnDemandResources and checked the flow in the simulator. It's working fine. When made a test flight release, I'm able to see the ODR field enabled and 1 asset file is available. But when installed, the resources are not getting downloaded.
I'm using Xcode 10.1 and changed build setting to legacy mode but it didn't work.
I found the solution for the problem I was facing.
"An asset pack is eligible for purging when all of the associated tags are no longer retained by any request. The resources associated with a tag may remain on the device for some time before it is purged, including across app launches."
Ultimately, the cache will get automatically purged if there is a memory issue, so it is only a cosmetic issue where users will potentially see your app as being larger than they expected, and then at some point down the line, it will be magically smaller.
So I copied my resources into another directory locally.
Another idea is I zipped my images and added zip file as on-demand resources. So after ODR got installed I extracted and copied my zip files contents locally. (I did this because finding the path for images in asset file was difficult in my case)
In our 030- content Spanish publication, we had a bunch of components localized and their Spanish content was used. Later, those same components were unlocalized.
Is there a way to retrieve the Spanish content from history? The history is now showing the history of the root component from the 020-content
When you unlocalize a Component, the local version will be deleted. It's a permanent operation that can't be rolled back.
As Frank suggested, it is permanent operation that can't be rolled back. The only option is to use old database if you got backup somewhere.
You may use old database backup on dev/test Tridion (if available) and can use content porter or manual copying from one that Tridion instance to another one.
As others have explained, that localization history is gone except in other environments or database copies (this is what makes template localization tricky).
On the delivery end, if you haven't republished or unpublished, your rendered component presentations (not exactly your content) may still be on your content delivery servers on the file system or as configured in the storage configuration (broker database).
On the business side, your authors likely (hopefully) have the correct translated copy.
Consider training authors or adjusting localization and read folder permissions to only the authors responsible for translation for those publications.
I'm trying fossil for the first time, and messed it up within minutes. I created a repository, then apparently ran commands in the wrong folders etc., eventually deleted the test repository, in order to restart. (Somewhere I had read that fossil was "self contained", so I thought, deleting a repository file would be ok. What is the correct way to delete a fossil repository?)
Now, with almost every command I try (incl. "all rebuild"), I get the error "not a valid repository" with the deleted repository name.
What now?
According to this post:
The "not a valid repository" error only arises
when Fossil tries to measure the size of the repository file and sees that
either the file does not exist or else that the size of the file is less
than 1024 bytes. It does this by calling stat() on the file and looking at
the stat.st_size field.
it seems likely that you have a missing or truncated Fossil file. Make sure you've actually deleted the repository file, and that your filesystem has actually released the file handles. Fossil stores some respository information in ~/.fossil, so you may need to remove that too.
rm ~/.fossil
In egregious cases, you may want reboot after deleting this file, just to be sure you're working with a clean slate.
If you're still having problems, try creating a new repository file in a different directory. For example:
cd /tmp
fossil init foo.fsl
fossil open foo.fsl
fossil close
If all that goes smoothly, you'll have to hunt down whatever remnants of the repository are lurking. As long as the file handles are closed, there's no reason you shouldn't be able to delete foo.fsl (or whatever) and call it good.
I have just experienced the exact same problem on Windows. I too seem to have found a solution. Here is what I did. I cannot guarantee that it is a universal solution or even a good one. In:
C:\Users\mywindowsusername\AppData\Local
There was a file named _fossil and a directory/folder named VirtualStore. I deleted both. This seems to have removed all traces of the repository. Note that the repository was still in the "open" state, as with your case.
Edit: After experimenting further, it would appear that VirtualStore is a temporary directory that will disappear after committing (a .fossil file will then appear inside the targeted directory).
My mistake was to create a repository at the root and clone: fossil proceeded to clone the entire C drive. Probably a common newbie mistake.
I've got a sqlite3 DB that I need to read (not write) sitting on a read-only filesystem. There is also a -journal file associated with the database, which is interfering with opening the database because the first thing the sqlite code wants to do is delete that -journal file and it cannot because the filesystem is read-only. Setting the journal_mode to off doesn't help because that apparently only applies to new transactions. Is there a way to tell sqlite3 to simply ignore all mention of a -journal file associated with a DB?
Unfortunately no.
The problem is that the existence of a journal file indicates that a transaction was left in an incomplete state, and needs to be rolled back by transferring the content of the journal file back into the database file.
This requires write access to the file system, and SQLite will not allow you to open the file without performing this rollback.
You can read more about this here: Read-Only Databases:
No SQLite database (regardless of whether or not it is WAL mode) is readable if it is located on read-only media and it requires recovery. So, for example, if an application crashes and leaves an SQLite database with a hot journal, that database cannot be opened unless the opening process has write privilege on the database file, the directory containing the database file, and the hot journal. This is because the incomplete transaction left over from the crash must be rolled back prior to reading the database and that rollback cannot occur without write permission on all files and the directory containing them.
If you don't care about the possible corruption that discarding the journal file might lead to, you can make a copy of the database file, and leave the journal behind. Though, if you have the ability to do that, I would in fact copy the journal file too, to a writable file system, and open that database as normal, which would roll back the transaction properly.
The copy on the read-only file system though is not usable in its current state.