I downloaded and started an instance of the HDP 2.4 as a VMWare sandbox. I just had a look for the directory structure, and found the there are the following 2 folders:
/usr/hdp/2.4.0.0-169
/usr/hdp/current
Why do I have two folders here as I didn't make any updates yet. I guess that the current folder is used for the platform tools like Spark etc. So if I need to update one of them (e.g. Spark) do I have to make the "changes" to that current folder or on both? Or will an update work completely different? Thank you!
/usr/hdp/current contains symlinks to versioned directories i.e. /usr/hdp/current points to /usr/hdp/2.4.0.0-169
Related
ArangoDB documentation for the Getting Started section of Foxx Microservices, begins with this paragraph:
We're going to start with an empty folder. This will be the root folder of our services. You can name it something clever but for the course of this guide we'll assume it's called the name of your service: getting-started.
My question is very basic. On a Linux system, what are the best options for the location of this folder? And what should its permissions be?
I see existing ArangoDB directories at these locations:
/var/lib/arangodb3/
/var/lib/arangodb3-apps/
/usr/share/arangodb3/
Should I place the getting-started directory under one of those locations or somewhere else?
The Foxx chapter received a structural overhaul and new content was added with the v3.4.0 release. I recommend you use the 3.4 Foxx documentation therefore.
You can put the getting-started folder anywhere, e.g. where you also put other project folders, like in ~/projects/arangodb/ or whatever suits you.
Read on in the Getting Started guide. Under the headline Try it out you find the steps how to deploy the service. ArangoDB will then place the files in the right folder, e.g. /var/lib/arangodb3-apps/_db/_system/getting-started/ (where /getting-started is the mount path, not the name of the project folder).
Also check out the guide about the Development Mode for faster iterations. You may use rsync to watch for file changes in your actual project folder and let it copy the changes over to ArangoDB's volatile Foxx app folder. This is much safer than to work in the deployed folder directly (if you remove the service you would also lose your changes, and in a cluster the files may get overwritten because the service changed on another coordinator).
An overview of Deployment options is also available, including Foxx CLI which can be used to bundle the files from your project folder and deploy them as service (foxx upgrade ...).
My installation of TeamCity 3.1 (yeah, it is old!) (installed on a Windows XP box) holds its temporary files under C:/TCBWork. How can I move that root? I would like to move it to another disk for better space management.
Thanks.
If you're talking about build agent working directory, it is set in buildAgent/conf/buildAgent.properties file (local TeamCity agent is under TeamCity/buildAgent directory).
And given that you have non-standard location for it, you'd already changed it previously :)
This might be a stupid answer, but assuming you're using NTFS you could mount an entirely different drive to the folder location of TCBWork.
I have worked with SVN, and with Apache but not together.
My customer has a live site at one address, and an SVN repository on another machine at another address.
I have checked out the whole 9 yards to a directory on my local (Windows XP) machine which is running Apache/2.0.59. (There are generally no problems configuring local sites.)
I get 3 directories in the checkout:
branches,
tags,
trunk
Which one should I use for my DocumentRoot ?
Thanks for reading.
You're probably checking out the wrong directory. Usually you check out either trunk, or a subdirectory of branches or tags. Otherwise you could end up checking out dozens of copies of the code, in slightly different versions.
As for the document root, that depends on how the project is organized. It could be the same as the directory you checked out, or it could be a subdirectory. The latter is more likely, since the project will probably contain some code that shouldn't be accessible from the web.
You definitely should use the one you need to use. Any that directory can contain sources. And we don't know which one you need in this particular case.
I have created an installation package using Wix which installs a Windows service on the user's machine. Currently, the files are being installed to [%ProgramFiles%\APLICATIONNAME].
Is this a future proof way of structuring an installation folder?
Should I be installing to [%ProgramFiles%\APLICATIONNAME\VERSION_NUMBER] instead?
Any recommendations would be greatly appreciated.
Thanks,
Arnie
Update:
Side-by-side installation of different versions will not be supported.
Version specific folders are no good. What you need to do is make sure all subsequent installers upgrade properly over the previous versions so that different folders are not required.
You may want to do something like ProgFiles\App 1.0 using the major and minor version number if you want to allow side by side installs of different versions. But with all of this it should ultimately be up to the user where the installed files end up.
As an additional note, if you are storing application data in the registry of the %AppData% folders then those are sensible places to use versioned folder names,
eg. %AppData%\Manufacturer\Application\1.0 and HKCU\Manufacturer\Product\1.0 or whatever.
We use this with a folder for each major release, this way if we decide to change our registry structure, rework data file formats, etc we only have to ensure compatibility between minor releases. Major releases can use a separate procedure to help the user migrate from a 2.x to 3.x release.
If side-by-side installation of different versions will not be supported I think [%ProgramFiles%\APLICATIONNAME] is good enough. However personally I prefer [%ProgramFiles%\COMPANYNAME\APLICATIONNAME].
So you know a lot of Mac apps use "bundles": It looks like a single file to your application, but it's actually a folder with many files inside.
For a version control system to handle this, it needs to:
check out all the files in a directory, so the app can modify them as necessary
at checkin,
commit files which have been modified
add new files which the application has created
mark as deleted files which are no longer there (since the app deleted them)
manage this as one atomic change
Any ideas on the best way to handle this with existing version control systems? Are any of the versioning systems more adept in this area?
Mercurial in particular versions based on file, not directory structure. Therefore, your working tree, which is a fully-fledged repository, doesn't spit out .svn folders at each level.
It also means that a directory that is replaced, like an Application or other Bundle, will still find it's contents with particular file names under revision control. File names are monitored, not inodes or anything fancy like that!
Obviously, if a new file is added to the Bundle, you'll need to explicitly add this to your repository. Similarly, removing a file from a Bundle should be done with an 'hg rm'.
There aren't any decent Mercurial GUIs for OS X yet, but if all you do is add/commit/merge, it isn't that hard to use a command line.
For distributed SCM systems like git and mercurial shouldn't be a problem as Matthew mentioned.
If you need to use a centralized SCM like Subversion or CVS, then you can zip up (archive) your bundles before checking them into source control. This can be painful and takes an extra step. There is a good blog post about this at Tapestry Central:
Mac OS X bundles vs. Subversion
This article demonstrates a ruby script that manages the archiving for you.
An update from the future:
If I recall, the problem with managing bundles in SVN was all the .svn folders getting cleared each time you made a bundle. This shouldn't be a problem any more, now that SVN stores everything in a single .svn folder at the root.
Bringing this thread back to daylight, since the October 2013 iWork (Pages 5.0 etc.) no longer allows storing in 'flat file' (zipped), but only as bundles.
The problem is not the creation of version control hidden folders inside such structures (well, for svn it is), but as Mark says in the question: getting automatic, atomic update of files added or removed (by the application, in this case iWork) so I wouldn't need to do that manually.
Clearly, iWork and Apple are only bothered by iCloud usability. Yet I have a genuine case for storing .pages, .numbers and .keynote in a Mercurial repo. After the update, it blows everything apart. What to do?
Addendum:
Found 'hg addremove' that does the trick for me.
$ hg help addremove
hg addremove [OPTION]... [FILE]...
add all new files, delete all missing files