I am using the latest version of SharpSVN. I would like to retrieve the latest working copy of a repository, but I would like to load it into a memory stream instead of saving it to disk. Is there a way to do this?
Thanks.
I assume you want one file in memory?
(It is hard to stream directories in a memoryStream).
But with SvnClient.Write() you can just copy a Subversion url to a stream.
Related
I am currently using Google cloud storage to store some files. From the PHP side, I am able to use these files just fine. Now I want to extend this functionality to store 4 good versions of these files so that I can change the file path through symlink(or any other alternative way is that's not an option) on PHP side in case the latest set of files get corrupted. I am wondering how to go about this.
I appreciate any suggestions that you might have.
Cloud Storage offers a versioning system as a feature that you need to enable. Versioning allows for you to save a file with the same title and the system archives the previous version and displays the new one. In this case, if there was a corruption, you would have to go into the Cloud Shell and retrieve the previous copy.
If you do not wish to go that route, I can suggest save 4 copies with distinct names(ie: fileName[number]). This way, you would take the newest file, retrieve a substring containing the number, and creating your new file based off the substring.
In both methods, you are able to roll-back to a previous version.
Cloud Storage does not allow for symlinks.
I am developing on two machines (switching PC and laptop during the week) and try to find the best way to synchronize a limited amount of dummy data in the mongodbs running on each machine.
My first quick & dirty idea was to track the relevant files, containing the collection data inside of a db folder (inside my project folder) by Git.
I saw for example files named e.g. collection-0-1858325258041703863.wt which seem to contain what i am after.
However i am not sure about the rest e.g. index-1-1858325258041703863.wt files, sizestorer.wt, WiredTiger.wt etc..
Which are the files i have to track and which are the ones i can ignore?
I am aware that i could create a mock server with only json files and that saving binaries in VC is bad, but still i am curious if this way is possible (Mainly because working with MongoCompass is way easier than editing json files)
I see from this question ( SQLite Database Copy ) that one must copy the sqlite database from the bundle to the working directory on installation for it to not be read-only. But what if the database is huge? I don't want it to take up twice the space it should. Is there a way to delete the original from the bundle? Any other workaround to avoid wasting so much space with a large db in the bundle that is never used after installation?
Thanks!
How big is very large?
And you can't modify the bundle in any way whatsoever, including deleting / renaming / modifying files etc.
If you want to modify your db you will have to copy it out of the bundle.
However, Apple have got a solution for low space. If you can recreate the data, you should copy your db into the caches folder, not the documents folder. That way it won't get pushed into the cloud and if the device is low on space, it can be cleaned out automagically by ios.
There is no way to delete a file from the application bundle resources directory (read only).
If your DB is too large to be copied I suggest to download the database when the application start for the first time.
Another approach is to create a database programmatically using sql statements upon installation instead of embedding a sqlite database in a bundle.
Is anyone aware of a hybrid version control and synchronising system?
I'm currently a happy mercurial user, but my projects usually contain a mixture of files.
Most of these (code, documentation, ...) I want to be version-controlled. This is why I use mercurial.
However, on the rare occasion I have files that I would like to synchronise between my working copies, but not version control.
For example, I version control the code I write to do image processing. This code can produce a whole bunch of output images which I'd like to have synchronised so I don't have to remember to shuffle them around my various computers, but there's no point having these version controlled.
To clarify - I am aware of extension to mercurial such as bfiles and bigfiles, which are handy for my image example, but I was just wondering if anyone out there knows of alternative ways to handle this. I just want the one system that I can tell "version control all files except those ones, which should be synced but have no history".
cheers!
EDIT: I could do something like adding a hg marksync <filename> that added <filename> to a list of files to be synced, and then adding a hook to hg push/hg pull that would (say) run rsync (or whichever sync tool) in the background, but I wondered if there was a less hacky solution (I think bfiles/bigfiles do something along these lines anyway).
Version Control System (any) doesn't care about synchronization of
not versioned data
besides default pathes
If you want sync any files - use specially designed for this task tools: f.e. rsync
This code can produce a whole bunch of output images which I'd like to have synchronised
Is this DATA or part of your CODE?
If data: Keep out of your versioning system, just don't go there. If it is part of your code (like layout images) check it in. Those are the only ways which are the generally accepted.
A nice solution for the data would be syncing OR generating them. So you might add a step after deployment to a server: GenerateImages().
edit: In addition to the comment made by the thread starter:
If the images are data and you need to process them on a different system don't think about the version control for your code. It is unrelated. The steps which would make sense to me, in order of processing:
Start with updating your image code, check it in versioning. Then deploy (yes this is deployment) the updated code to the cruncher computer. Now code is done.
Then you have tasks which the number cruncher should handle. Like processing the images. So start that processing from either the cruncher itself (probably some queue happens there) or from a central dispatcher.
Then you have the results locally at the cruncher. Now something has to happen with that data, so that's also part of your software. Decide whether you want the cruncher to send them to some central storage, your workstation or another location. Let the software handle that. This is the most hard part as I read through your question. Many solutions are possible from just FTP/network transfers to specific storage solutions. Willing to help but need more info about the real issues, amounts, sizes etc. on these parts.
If the new updated version of the image processor makes the old generated images obsolete implement that also in your code, by for example attaching an attribute to the files generated, a seperate folder or another indication. That way you could request the cruncher after update to re-generate any obsolete files.
I'm gonna release a new version of my app. The previous version used some files which in the newer version are changed and need to be processed. I want the older files to be automatically deleted when the user updates the application, otherwise the application sees them and will process them (resulting in an error because the format of the files changed).
Is there an option to do that?
Thank you.
Since you are processing these files, one option is to somehow put the format version in the files or in folder path. Bake that version into a constant in the app.
The app can either always look for those files by appending the constants to the path where you get these files, or look into the data of the file to get the format version and handle it properly (delete, redownload etc...).
Another benefit is that if you release your app and the format version does not change (likely - you just fixed bugs), you don't have to delete and re-download those files. You also don't have to change anything or update any routines - simply don't change the file format constant and it won't change your files. If you change the format of the files, update that constant and it just works.
It's always a good practice to get the version of your app from the bundle in code and perform necessary changes as needed:
NSString* versionString = [[NSBundle mainBundle] objectForInfoDictionaryKey:(NSString *)kCFBundleVersionKey];
Then you can compare this string (or float version of the string) to determine what changes to make to the data. You might delete the old data (as in your case), or extract some of the old data and create new data (the usual way), or the app may need no changes at all.
The BIG thing to keep in mind is you may upload/release several versions of an app and some users may not have downloaded the newer versions. Because of this, it's good practice to have methods update the data based on the version string, instead of expecting it to be the last version of the data.