I've recently tried to upgrade my Trac from version 0.12.2 to version 1.0.1 by following the upgrade guide on the Trac website. It mentioned to remove the attachment folder for the ticket and wikis because the folder has been changed from /path/to/project/attachments to /path/to/project/files/attachments. So I backed up the attachment folder and after the upgrade I put it back into my project folder under files/attachment.
When I try to access an attachment in the new trac environment it has trouble finding it. It's trying to look for the attachment in this
/path/to/project/files/attachments/fad/fadece229cc1ef23ce5f467cec5f4675cec7ace5ad7c148c
folder, and the file names are in hashed code like
b10a69f289e6ae408878d2286758a3121be4759.txt.
instead of its actual name. Any files that are uploaded after the upgrade will go into this folder instead of the respective Wiki or ticket folder like it used to do before my upgrade. Has anyone experienced this issue while doing the Trac upgrade?
Upgrade to 1.x includes a file store redesign including changed file paths.
File names with path are hashs now, computed from user-supplied names, and no the lightly encoded names. Consequently the backup doesn't match the expected new paths at all - as you experienced.
The conversion of an existing attachment storage is part of the upgrade script, so you clearly misread the upgrade guide. The removal was meant for attachment sub-directories not managed by Trac core, and as post-upgrade-cleanup.
You should rather leave the files and let the store get transformed for you. Ensure you read the logs of the upgrade process to notice delicate issues immediately.
Related
I recently installed VQmod for opencart and I've tried to add my first vQmod xml file.
The VQmod installation was successful and I see the message
VQMOD ALREADY INSTALLED!
when I visit the /vqmod/install/ URL as expected
The extension I tried to install can be found here
I added the xml file to the root folder of my site and the /vqmod/xml/ folder but I don't see a change. No new module appears in the modules page and I don't see the extension working as expected. I also don't get any error messages
The file needs to be in the /vqmod/xml/ folder as you've rightly done (the root of the folder one can be deleted as it's not required). As for the mod not showing up, vQmods don't add modules to anywhere - they virtually edit files in certain spots. From the looks of the extension you need to go to CATALOG > PRODUCTS in your admin and then you will notice you can edit products there. A few of things to check
You are using the correct version for your OpenCart install and that it is compatible
If you don't, you'll need to get that version instead
You have files in /vqmod/vqcache/ and that if you delete them and refresh your OpenCart store, the files regenerate
If they don't, check the permissions on the directory and that you have the OpenCart version of vQmod, including the /vqmod/xml/vqmod_opencart.xml file
You have no errors from the mod (see /vqmod/logs/ followed by the day name such as Tue.log)
If you do, contact the developer to get a fix if they can. Remember that while vQmods can work well together, that depends largely on the competence of the developer to make it as dynamic as possible. Conflicts can always occur however
download the VQMOD from this link https://code.google.com/p/vqmod/downloads/list
upload the ZIP file (case of server)
extract the ZIP file and past root folder directory (in case of localhost)
exp (site folder name is shop (shoo/vqmod))
run on url (http:/open/vqmod/install/)
exit
How to save/restore Sublime Text 2 configs/plugins to migrate to another computer? states that, to backup a Sublime Text 2 installation, a user should preserve the ~/Packages/User directory (from the user's local data folder on whatever OS they're using).
However, http://andrew.hedges.name/blog/2012/01/19/sublime-text-2-more-sublime-with-a-drop-of-dropbox and most other walkthroughs for using Dropbox to sync Sublime's settings specify three directories: ~/Packages, ~/Installed Packages and ~/Pristine Packages.
What is the functional difference between backing up just ~/Packages/User, and the other 3 directories?
I think that Packages/User is the one in which you are supposed to put settings (according to Sublime's official and unofficial documentation). However, some people put them in the other folders from time to time.
The Dropbox advice may be a hedge against poor practice.
From here:
Installed Packages is:
You will find this directory in the data directory. It contains a copy
of every sublime-package installed. Used to restore Packages.
These are the packages installed as sublime-packages. I don't think package control uses this, but if you install something as a sublime-package maybe you want to keep it?
Pristine Packages is:
You will find this directoy in the data directory. It contains a copy
of every shipped and core package. Used to restore Packages.
So essentially a list of .sublime-package files used to restore if you break something.
Packages is:
The packages used by Sublime Text, either installed as part of sublime, or the plugins.
User is:
The user directory is your personal directory, containing configurations, additional snippets, etc.
Below are my personal views on what to save, so feel free to ignore it if you would like.
I would have to agree with the post saying just save the User directory, as Package Control will grab all of the plugins in the list if they aren't already installed. I didn't see this mentioned in that post, but you can also add repositories (by specifying a URL) to Package Control, which allows you to install Packages outside of those submitted to Package Control, but still hosted somewhere. One of the arguments I can see to saving the Packages directory completely is if you are using plugins that aren't hosted anywhere (though these could probably be moved to the Packages directory without any problems).
The Installed Packages and Pristine Packages are used to restore packages, so I wouldn't think these would be needed, but I'm sure there is some use case where it is.
Anyways, realize I got off topic a bit at the end there, but hope everything before that helps clarify.
I'm trying setup the Versioning bundle in RavenDB: http://ravendb.net/bundles/versioning
The installation instructions are pretty straight forward:
Simply place the Raven.Bundles.Versioning.dll in the Plugins
directory.
I've tried this do this by creating a "Plugins" directory under the Server directory (the Server directory contains the Raven.Server.exe), and dropping Raven.Client.Versioning.dll into that Plugins directory.
However, when I run RavenDB after that (either from the command line or as a service), it doesn't give me any indication that it has recognized the plugin, and when I save/edit new documents no versioning is being applied.
I've tried running with the default plugin directory settings (which supposedly automatically looks in the Plugins directory), and I've tried manually adding the PluginsDirectory setting to Raven.Server.exe.config, to no avail.
Has anyone been able to get plugins working, specifically the versioning bundle? Do you hae to do anything special?
Mike,
It is supposed to just work. Take a look at the statistics, you should see the versioning trigger registered there.
It is important to ensure that:
You are using the same version of the dlls
You restarts RavenDB after copying the directory
You don't reference another Raven/PluginsDirectory in the configuration
It is probably better to follow this up in the mailing list.
For Raven v2, you'll also add the bundle name to the the Raven/ActiveBundles property on a database document. The names should be semicolon-delimited.
For example, I have a database called MidwestAnimalRescue. To enable the Periodic Backup bundle and the Versioning bundle, my document will look like this:
I'm using Trac 0.12.2 that came as a part of Bitnami Trac Stac.
I am very new to Trac & just started with Trac, working with a local repository on a desktop a few weeks ago & created some issues. Now I wanted to transfer the all those issues onto my new Trac installation on another desktop. So I simply tried replacing the empty(I believed) database folder of new installation with my old Trac DB folder.
Specifically this folder:
C:\BitNamiTracStack\repository\db\
When I tried doing so, the admin tab on the trac interface disappeared.
Also I got a message:
Warning: Can't synchronize with repository "(default)" (The repository directory has changed, you should resynchronize the repository with: trac-admin $ENV repository resync '(default)'). Look in the Trac log for more information.
How do I successfully transfer my issues from one desktop to another ?
Check your installation and find the correct directory called 'Trac environment' as per Remy's advice.
While his answer is the safe road and general advice without doubt, you may still succeed with a less complete transfer, depending on what you already put into the Trac environment in question. Assuming you do use BitNami's default Trac db backend (SQLite) you'll need at least
the latest db named trac.db from the db folder
the configuration file conf/trac.ini
If you've worked with attachments to tickets or wiki pages, the whole directory structure below attachements is needed as well.
Other things might not have been touched by a self-declared "very new" Trac user within the first weeks. Of course a diff -Nur <path_to_old_dir> <path_to_new_dir> | <your_favorite_editor> will remind you of anything you may have already forgotten.
You shouldn't copy the database alone, but the complete Trac environment. That's the directory containing the attachments, conf, db, htdocs, log, plugins and templates directories. In your case, this seems to be the directory:
C:\BitNameTracStack\repository
(I'm not familiar with the BitNami stack, but the name "repository" sounds suspect. I hope they don't put the Trac environment below the Subversion repository.)
See the official Trac documentation on backing up a Trac environment and restoring it. You should be able to use this to migrate your config to another server.
I am working on a small toy project who is getting more and more releases. Until now, the documentation was just a set of pages in the wordpress blog I setup for the project. However, as time passes, new releases are out and I should update the online documentation to match the most recent release.
Unfortunately, if I do so, the docs for the previous releases will "disappear" as my doc pages are updated to the most recent version, therefore I decided to include the documentation in the release package and to keep the most recent documentation available online as a web page as well.
A trivial idea would be to wget the current docs from the wordpress pages, save them into the svn and therefore into the release package, repeating the procedure at every new release. Unfortunately, the HTML I get must be hacked by hand to fix the links (or I should hack wordpress to use BASE so that the HTML code is easily relocatable, something I don't want to do).
How should I handle the requirements of having at the same time:
user-browsable documentation for the proper version included in the downloadable package
most recent documentation available online (and properly styled with my web theme)
keep synchronized between the svn and the actual online contents (in wordpress, or something else that fits nicely with my wordpress setup)
easy to use
Thanks
Edit: started a bounty to see if I can lure more answers. I think this is a quite important issue, and it would be nice to have multiple hints and opinions for future readers.
I would check your pages into SVN, and then have your webserver update from its local SVN working copy when you're ready to release. Put everything into SVN--wordpress, CSS, HTML, etc.
WGet can convert all the links in the document for you. See the convert-links option:
http://www.gnu.org/software/wget/manual/html_node/Advanced-Usage.html
Using this in conjuction with the other methods could yield a solution.
I think there are two problems to be solved here
how and where to keep the documentation aligned with the code
where to publish the documentation
For 1 i think it's best to:
keep the documentation in a repository (SVN or git or whatever you already use for the code) as a set of files, instead of in a db as it is easier to keep a history of changes (an possibly to stay in par with the code releases
use an approach where the documentation is generated from a set of source files (you'd keep the sources in the repository) from which the html files for the distribution package or for publishing on the web are generated. The two could possibly differ, as on the web you'd need to keep some version information (in the URL) that you don't need when packaging a single release.
To do "2" there are several tools that may generate a static site. One of them is Jekyll it's in ruby and looks quite complete and customizable.
Assuming that you use a tool like jekyll and keep the files and source in SVN you might setup your repo in this way:
repo/
tags/
rel1.0/
source/
documentation/
rel2.0/
source/
documentation/
rel3.0/
source/
documentation/
trunk/
source/
documentation/
That is:
You keep the current documentation beside the source in the trunk
When you do a release you create a tag for the release
you configure your documentation generator to generate documentation for each of the repo/tags//documentation directory such that the documentation for each release is put in documentation_site/ directory
So to publish the documentation (point 2 above):
you copy on the server the contents of the documentation_site directory, putting it in the same base dir of your wordpress install or linking from that, such that each release doc can be accessed as: http://yoursite/project/docs/relXX/
you create a link to the current release documentation such that it can always be reached as http://yoursite/project/docs/current
The trick here is to publish the documentation always under a proper release identifier (in the URL, on the filesystem) and use a link (or a redirect) to make sure that the "current documentation" on the web server points to the current release.
I have seen some programs use help & manual. But I am a Mac user and I have no experience with it to know if it's any good. I'm looking for a solution myself for Mac.
For my own projects, if that were a need, I would create a sub-dir for the documentation, and have all the files refer from the known-base of there relatively. For example,
index.html -- refers to images/example.jpg
README
-- subdirs....
images/example.jpg
section/index.html -- links back to '../index.html',
-- refers to ../images/example.jpg
If the docs are included in the SVN/tarball download, then they are readable as-is. If they are generated from some original files, they would be pre-generated for a downloadable version.
Archive versions of the documentation can be unpacked/generated and placed into named directorys (eg docs/v1.05/)
Its a simple PHP script that can be written to get a list the subdirs of the /docs/ directory from the local disk and display a list, and highlighting the most recent, for example.