We are managing our development with Subversion over HTTPS, Bugzilla, and Mediawiki. Some of our developers have expressed an interest in migrating to Trac, so I have to evaluate what the cost of doing so would be.
For both the wiki and bugzilla, we would need to either migrate the existing data into Trac or a way to integrate with trac. Having two apps to create wiki pages or log bugs would not be acceptable. Also, currently each of these applications requires a separate sign on so we would need to map each of these accounts into Trac.
So know of any easy methods of importing or integrating these systems with Trac and/or a tutorial for doing so?
For Bugzilla, Trac has a script bugzilla2trac.py that will automate the process of importing Bugzilla bugs to Trac tickets for you. Of course, Trac doesn't have support for blocking/blockedby tickets out of the box, so if you want to import this data too, you'll have to use the MasterTicketsPlugin and then modify the script yourself (which is what we did when we migrated).
Wiki pages
If you could export your pages to text files you could import them using the Trac-Admin: http://trac.edgewall.org/wiki/TracAdmin wiki import command. Some formating clean-up migration might be in order
Tickets/Bugs
This script by Tom Lazar give you ability to synchronize the tickets system with a CSV file.
This gives you an ability to migrate from BugZilla: http://bitten.edgewall.org/wiki/TracImport
You could also check out this resource: http://trac.edgewall.org/wiki/TracSynchronize
For MediaWiki there exists a script as well: http://trac.edgewall.org/ticket/5241
It has some bugs, but imports all important information (pages, revisions, images, users). Together with the other mentioned script you should be able to migrate to Trac.
One thing that is not covered (yet) by the import script is the resolution of bugzilla links of the kind bug X or bug X comment Y.
One solution for this is to use the RegexLinkPlugin (http://trac-hacks.org/wiki/RegexLinkPlugin) with the following configuration in the trac.ini file:
[regexlink]
regex1=\bbug (?P<bug_id_comment>\d+) comment #(?P<commentid>\d+)\b
url1=http://your.trac.instance.com/ticket/\g<bug_id_comment>#comment:\g<commentid>
regex2=\bbug (?P<bug_id>\d+)\b
url2=http://your.trac.instance.com/ticket/\g<bug_id>
Related
Im currently working on a big project with more then one team.
Lets say in the project there are some modules that each team working on.
In addition we are using gerrit for sometime now and there is something i couldn't find out.
My question is the following:
Is there a way to tell Gerrit that only specific people/group(on Gerrit) will have permission to review code (+2) on specific path/module on the project?
This is possible, and can be achieved by using the Gerrit OWNERS Plugin. I haven't configured this plugin myself, but we use this in our codebase to protect certain areas of code.
Every folder that needs protection contains a file named OWNERS that has the following structure.
inherited: true
owners:
- user-a#example.com
- user-b#example.com
Here is the link to a readme for the plugin. Hope you can figure out how to configure it.
https://gerrit.googlesource.com/plugins/owners/+/refs/heads/master/README.md
I think you can do this by making two separate commits. You can later add the group that you want to review the code on that specific path using gerrit interface.
I wonder if there is a good way of deploying database changes made on a typo3 website (on dev) to a live website?
In Magento for example there are folders containg sql install statements (for the structure, new tables etc.) and data install scripts (inserting data into the tables).
These scripts are automatically executed when deployed to live.
Good ways of getting rid of manual database adaptions are welcome.
Thanks!
cweiske explained it well, for common admin it's enough to know that Install Tool has Database Analyser > Compare functionality, which is dedicated for handling DB schema differences.
TYPO3 extensions have their ext_tables.sql files which define the database structure they need.
When installing the extension, the necessary database structure changes are made by the TYPO3 extension manager. You can also apply the changes yourself by using the install tool -> database update.
So as long as your extensions have the correct table definitions, you're fine and can rely on TYPO3 to update the actual database.
I've got a DotNetNuke system (v 5.6) that's hosting several different portals, and I'd like to move one of them to another hosting provider. What's the easiest way to do this?
Every web site I find that claims to explain how to move a DotNetNuke site essentially says "Copy the entire database over to the new system." That's great if you've only got one portal in the database, but I've got a dozen of them. I only want to move one portal, not all of them.
Exporting the site to a .template is another popular suggestion. This exports the structure of the site (all the tab definitions, for example), but it doesn't include any of the actual HTML content. As such, that's essentially worthless.
There must be a reasonable way to do this short of trying to strip one individual portals data out of every single DNN table. Right?
When you export a site template, you can include the content of the site, as well (for the modules that support portability, which includes the standard HTML module). This is how the default site template has all of its content. When you do this, there will be a .template.resources file that you'll need, as well as the .template file.
The other option is to do a full backup and restore, and then remove the other sites once you've restored. If you have significant content in a module that doesn't support portability, I think this will be your best bet.
FYI, I did find a solution from someone over on the DotNetNuke forums.
Create a 2nd version of that install, then delete all the other
portals. Move the install with the one portal. We've done this several
times with installs with lots of portals and it works just fine. Yeah
there's still some noise left in the db, but it's a quick and
effective way of doing things.
Edit note that this will give you an install with 1 portal. You can't detach a portal from one install and reattach it to an existing
install (well, you can, but basically you have to export the portal as
a template and that isn't 100%)
This is the approach I took, and sure enough, it works.
In a nutshell:
Mirror the files for the web site to another server.
Mirror the DNN database to another server.
Log in a Host on the new setup and delete all the portals but the one you want to migrate.
Delete any module definitions that are not in use by the remaining portal.
Open up your favorite SQL tool and delete any entries in the Users and UserProfile tables that no longer have a matching row in the UserPortals table. DNN does not remove these by default, which is frustrating.
Hop in to Windows Explorer and delete all of the Portal folders you no longer need (ie: /Portal/1, /Portal/2, etc.)
Back up the database using Enterprise Manager to create a .bak file
Make a .zip of the entire DNN installation folder.
You now have a .bak that contains the database and a .zip that contains the files. Send those off to the new hosting company, and you should be all set. Just make sure to update your web.config to set the connection string properly to point to the new database server at the new hosting company.
It's just that easy. ;)
I was wondering if it is possible to use groups specified in e.g., an apache authgroup file in allow_read and/or allow_push etc.
So basically what I do is I am using apache with an authfile and authgroup file to authenticate users.
Now I want to restrict some repositories using allow_read from being shown to users in a specific group specified in the authgroup file.
Let's say I have sam, frodo and sauron in my auth file and I have a group hobbits containing sam and frodo in the authgroup file.
So instead of writing:
allow_read = frodo, sam
I tried
allow_read = #hobbits
but that does not seem to work. Does anybody know whether this is actually supported? The idea is if I have say 10 Repositories only readable for hobbits and I add a hobbit I only have to change the authgroup and auth file and not each repository hgrc file.
Thanks in advance
Mercurial does not have any builtin support for groups. There is a patch from a user that adds group support, but the coders seemed hesitant to include it by default, they want the contributor to make a plugin out of it instead. As of April 2013 they seem to have accepted it, but I still see no trace of it in the version currently shipped with Ubuntu (2.7).
Controlling groups in Apache, as suggested by Joel, doesn't give you any fine granular control when you have more than one repository, so it's no use (at least not for me).
I ended up using the open source tool SCM-Manager for it. SCM-Manager acts as a frontend for SVN, Git and Mercurial and has support for various user directories (including LDAP and Crowd) as well as its own user directory.
I'm using mod_proxy to integrate it in my Apache configuration and it works quite well.
It appears you'll need to do your group controlling in Apache rather than in hgrc files, as the documentation for hgrc mentions only user names.
You'll want to have a read of Configuring Apache on the Publishing Repositories page. Section 7.4 seems to contain the information you'll need to set up what you want.
I want to move tickets from one trac instance to another. Is there some utility that will help me do this? The current instance is running on my server using a sqllite db. The instance that I want to move to is on sourcerepo. Are there any utilities that can help me migrate these tickets?
Since sourcerepo also provides a redmine installation, I wouldn't mind if I could move tickets from trac to redmine.
Take a look at what the Trac wiki has to say about migrating data between Trac installations.