Since I am using a cloud folder with limited space availability for my R project, I decided to disable packrat for my project and use the local library instead.
It worked, but the packrat folder inside my project folder is still there, taking quite some space. Can I just delete it?
thanks
Giulia
I'm lacking official confirmation, but I'm going to say yes you can safely delete the packrat directories and files after disabling it. I've tried it and see no downsides yet. If you don't disable it first there will likely need to be some additional cleanup to do. If you need packrat again you should be able to start over the same as usual.
Related
I work alongside two other developers and we seriously need a method of version control implementing within our workflow. Currently we're centralising data using a Synology NAS (which is backing itself up to Google Drive) but the bulk of our development work is done on our local machines just to speed things up.
We've been running into issues lately where we have lost track of file versions when moving between local, centralised and live copies due to our set up. We have suggested, between ourselves, using Git but none of us are experienced with it and after spending today doing some research I feel as though it is not going to actually help. It feels quite clunky and as though it slows the process down. Maybe I'm just doing something wrong?
Anyway, if anybody could suggest a better way/optimal git config they have used or had experience with I would be greatly appreciative.
Thanks in advance,
Ethan.
If you don't want to use git, then I suggest to use SVN. You can find a free SVN repository here: https://riouxsvn.com/
Hope it works!
Preparation to use git to version control your WordPress theme:
1. Remote repo. This is the place where the versions to be managed and controlled. You can create a remote repo by git init --bared. Or you can use github, bitbuckte etc to host your remote repo.
2. Local repo. make changes the develop on it. You can use below commands to work with your remote repo:
git clone /path/to/remote/repo
git add filename #after you add/modify a file
git commit -m 'message' #commit your changes in local repo
git push #push your local changes to remote repo
More details about git, you can refer git book .
I am looking for a solution that would allow me to have a network share where people can access (read-only) the artifacts from an Artifactory repository.
Why? We use Artifactory to also keep track of big binaries like installation kits, ISO images and so on and it takes a lot of time to download all of them (sometimes as zips), unpack and run them. If these would be exported to a NFS/SMB share people would be able to only mount them in order to use them.
How can we achieve this? Please keep in mind that we also want to automate this, so the files would be updated by Artifactory when needed.
Artifactory supports WebDAV out of the box.
It seems that's not possible at this moment and there is a feature request for enabling it:
https://www.jfrog.com/jira/browse/RTFACT-8302
Feel free to vote and to comment on it, allowing jFrog to realise how important is this use case.
I guess they should be able to provide a script that does mirror/sync a repository to a NFS share but that would almost double the storage space needed.
Instead if they would use hardlinks or symlinks to create a browsable tree of the repository inside the storage directory, this would be solved and no sync will be needed.
I'm currently stuck with an Installshield project for installing our ASP.Net Application and need to implement upgrading. From my initial investigation it seems extremely complicated for what is essentially copying over a number of files.
Of the options available: patches and small, minor and major upgrades, what seems to most suit our needs is a patch but it is done as a separate .exe.
Is there a way to include patches in the full setup.exe or another recommendation that makes the whole process less complicated.
EDIT
Any alternative recommendation still needs to be done as part of an installer.
No, there is no way to include patches in the installer setup.exe. Patches, as well as small and minor updates, are applied to already installed application. I mean users already used the original installation package to install your application. And patch update contains only small set of files that are modified.
What you want is a major update. This kind of package contains all the required files, and it can be used to install the application for the first time. In case where the application is already installed, this kind of installation package will automatically remove the old version and install the new one.
If it involves only copying files then IMO, the best option is to give the bunch of files in needed directory structure and ask to overwrite existing copies. A slightly more user-friendly measure would be to zip up the directory structure along with a batch file and ask to unzip it in the app directory under some designated folder and then run the batch file to overwrite files.
recently, i upgraded to Flex Hero 4.5 and created a new workspace. Then, i imported a project from the former workspace and started working. when i tried to upload the project from the new workspace to codereview, i got the error message: could not guess version control system. Are you in a working copy directory? How does one resolve this issue?
thanks
I have read somewhere that i need to checkout my svn but i thought that you only checkout when you want to get a folder/file from the svn.
Sounds like you've got a bit of a mess unfortunately. Hopefully you're not in the habit of doing a ton of changes without checking in. I would suggest you:
Back up your latest changes to a safe location
Check out the project from SVN into your new workspace (which is what you should have done initially) - creating a brand new project folder
Merge the changes you've made into the now-correctly-versioned copy of your project (you could do this by just copying files from the "latest"/project backup folder overwriting the SVN versioned files, but if you do--do NOT overwrite any .svn folders). You could also use a tool such as WinMerge or WinDiff to find differences between the two projects (of course ignoring .svn folders).
If you have a small number of changes it shouldn't be bad, but if there's a lot, you might want to follow SolarBear's branch suggestion, if WinMerge isn't going to cut it.
If I understand correctly your latest comment, you did a svn export on your code. The export command, as the doc mentions, creates a "clean" directory tree, i.e. without the .svn directory. So basically, these are files not controlled by SVN; also, you lose all the history of your files. The best way would have been, I think, to do a checkout in your new workspace and then work from there. It could take some time, but it's much easier to manage afterwards.
One possible way to make this work would be to checkout a clean copy your code somewhere safe and then merge your changes into this clean copy. However, if your trunk or branch changed a lot in the meantime, this could be very, very tedious. I could then suggest to branch your trunk, checkout that new branch, slowly merge your changes into that branch and when you're done and everything's working OK, merge the branch back into the trunk.
After months using Drupal for my websites I noticed module uninstall tab in the modules list.
I've always uninstalled my modules by deleting their folders from filesystem (after disabling them). I was wondering if this is the wrong way to remove them.
Thanks
When you uninstall the module, rather then just disabling and removing, you let the module clean up after itself, including:
Delete tables it created
Delete system variables it used.
So uninstalling is a good clean, for the health of your database. Things will work fine not doing it, but why keep unused tables in your database?
Note:
It's up to the module creator to create the code needed to do the clean up, so not all modules do this very well.
I've always uninstalled my modules by deleting their folders from filesystem (after disabling them). I was wondering if this is the wrong way to remove them.
The files used from a module is not the only thing a module leaves on a Drupal site; there are database tables, Drupal variables, cached values that still need to be removed, when uninstalling a module. It's also possible that a module adds rows into a database table created from a different module.
Deleting the module files, you are not removing any reference to the module contained in the table system. This means that if you are copying back the same module after you deleted it, and you did delete its tables, the module is not going to re-create the database tables it needs.
I would definitively say it is the wrong way to uninstall a module.
Uninstalling is sometimes needed, as hook_install() won't fire if a module is just disabled. So if for example a module has some corrupted data, disabling and re enabling won't remove that.
You will probably be ok in your approach. However one thing to be weary of is doing the following.
Disable
Remove folder
At a later date put module back again (not the same version)
Uninstalling.
The reason for this is hook_install() and hook_uninstall() should be mirror images of each other. Update hooks are used to keep a module schema and settings up to date with what is provided in hook_install(), if you were to use an updated module to uninstall (without updating) it will be trying to uninstall a different set up to what is expected. The risk is slim that something would go badly wrong, but it is worth being careful.
The uninstall tab will remove anything in your database related to the module. This operation requires the module to still be present in your modules directory.
Simply deleting the files isn't 'wrong', but it will leave unneeded cruft in your database. The uninstall tab will not remove the module files for you, you need to do that yourself as you have been doing.
Drush makes the module uninstall process much more pleasant, with something like:
drush pm-disable [module] // or its shorthand drush dis [module]
drush pm-uninstall [module]
In fact, Drush makes just about everything more pleasant (downloading/installing modules, dealing with install profiles, creating DB backups, and my personal favorite, updating your entire code base). If you're not already using it, I highly recommend giving it a try.
You can check this link - modules may have some additional uninstall instructions for them, but it looks like majority of them don't - that's why you didn't have any issues :)