Re: [Trac] Re: Merging two Trac instances?

[W. Martin Borgert]

Hi,

reminder for myself and everybody else:
It is not very difficult to merge two Trac instances, but the
specific steps depend on your usage.
Thanks to Ryan for very useful hints!

Of course, the merge is not "perfect", because intertrac links
between the instances are not changed automatically, nor ticket
references in the wiki etc.

In my case I could leave out some things:

 - users were mostly identical (same team)
 - ticket custom fields, priorities, resolutions, severities, and
   ticket types, versions were default
 - no plugins, that are using the database

This leaves:
 - ticket components
 - ticket milestones
 - repositories
 - wiki

What I did:

 1. *Backup* everything, i.e. both instances

 2. Add useful prefixes to all ticket components in both instances
to avoid collision

 3. Add useful prefixes to all ticket milestones in both instances
to avoid collision

 4. In one of the two instances add an offset to all ticket numbers
to avoid collision (id in table "ticket", "ticket" in tables
"ticket_change" and "attachment")

UPDATE ticket SET id = id + 1;
UPDATE ticket_change SET ticket = ticket + 1;
UPDATE ticket_custom SET ticket = ticket + 1;
UPDATE attachment SET id = id + 1 WHERE type = 'ticket';

 5. Dump the relevant tables. To dump a single table:

pg_dump  --format plain --verbose --file ticket.sql \
--table ticket dbname1

And copy it to the merged database:

psql dbname2 < ticket.sql

I removed everything from those files, but the actual COPY
command. Not sure, whether this was needed.

Same process for all six or seven tables.

 6. Add the git repositories in the merged instance.

 7. Copy all attachments from one instance to the other, more or
less it is:

cd instance1/files/attachments;
tar cf - * | ( cd ../../../instance2/files/attachments;
   tar xf - )

I had to adjust minor things like git post-receive hooks, nginx
paths etc., but that's more or less it.

Many thanks again to Ryan!

Cheers

--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: Merging two Trac instances?

[Ryan Ollos]

On Tue, Jan 16, 2018 at 2:06 PM, W. Martin Borgert 
wrote:

> > * Wiki is simple if there are no page name collisions. You can just
> > export/import using TracAdmin. However, you can also do this by dump/load
> > of the wiki table, and since you have to handle a number of other tables,
> > that is the way to go.
>
> Will export/import include history? If not, I'll go for dump/load.
> I will check name collisions before and do renames if necessary.
>

That's a good point. The trac-admin export will not include history, so you
probably want to use a database dump/load.

You'll also need to move attachments, contained in the environment "files"
directory.

- Ryan

-- 
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: Merging two Trac instances?

[W. Martin Borgert]

Many thanks for your quick reply!

On 2018-01-16 13:14, RjOllos wrote:
> * Git repository is very simple: Just add the Git repository to the 
> configuration and resync if you have a cached repository type.

Yes, that's what I imagined.

> * Wiki is simple if there are no page name collisions. You can just 
> export/import using TracAdmin. However, you can also do this by dump/load 
> of the wiki table, and since you have to handle a number of other tables, 
> that is the way to go.

Will export/import include history? If not, I'll go for dump/load.
I will check name collisions before and do renames if necessary.

> * Milestones are stored in the database, so you can do a database dump/load 
> of the table, and it will go smooth assuming there are no naming collisions

OK, renames will be necessary anyway for usability.

> * You can dump and reload tickets from the database, but the ticket 
> numbering will change, assuming the ticket numbering of both system started 
> at 1. You could dump the ticket table, change the numbering by an offset 
> and load into the new system. You'll need to modify the attachments, 
> ticket_custom and the ticket_change tables as well, to account for the new 
> ticket ids.

Sounds like the fun part :~)

> * There are some other tables you should be concerned with, like Versions, 
> Priorities ... and other associated with the ticket system. Also, the 
> permissions table. Here is the list of tables:
> https://trac.edgewall.org/wiki/TracDev/DatabaseSchema

This is very helpful!

>  * You can ignore: auth_cookie, cache, node_change, revision. As mentioned, 
> I'd also ignore the repository table and just add the new repository 
> manually.

Yes, there are only few repositories anyway.

> * Users - depends on the authentication mechanism. It might just be a 
> matter of merging htpasswd or htdigest files.

Most users have access to both systems anyway. I'll probably just add
the missing ones manually.

> I'd start with a backup of both systems and start working on a script. Feel 
> free to post here for advice on the script as it progresses. If you refine 
> the script it could be posted as a script on trac-hacks.org, so happy to 
> help you get it refined.

This sounds like the way to go. 

> The trac-admin hotcopy utility can be used to dump the database on the 
> system you are migrating away from.
> 
> Which Trac version and which database type? Do you have plugins installed?

1.2 and PostgreSQL 9.6. There are some plugins, but IIRC, they are all
purely UI related. No tables involved.

Thanks again for the help and all the specific hints!

Cheers

-- 
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

[Trac] Re: Merging two Trac instances?

[RjOllos]

On Tuesday, January 16, 2018 at 8:28:57 AM UTC-8, W. Martin Borgert wrote:
>
> Hi, 
>
> I like to Trac instances. Both instances have tickets, wiki, and git 
> repos. 
> I'm using Trac 1.2 with PostgreSQL on Debian stable. 
> I came across 
> https://reinout.vanrees.org/weblog/2009/05/28/merging-trac.html, 
> but it does not talk about tickets, users, milestones, etc. 
> Does anybody know of a more complete recipe? 
>
> TIA! 
>

* Git repository is very simple: Just add the Git repository to the 
configuration and resync if you have a cached repository type.
* Wiki is simple if there are no page name collisions. You can just 
export/import using TracAdmin. However, you can also do this by dump/load 
of the wiki table, and since you have to handle a number of other tables, 
that is the way to go.
* Milestones are stored in the database, so you can do a database dump/load 
of the table, and it will go smooth assuming there are no naming collisions
* You can dump and reload tickets from the database, but the ticket 
numbering will change, assuming the ticket numbering of both system started 
at 1. You could dump the ticket table, change the numbering by an offset 
and load into the new system. You'll need to modify the attachments, 
ticket_custom and the ticket_change tables as well, to account for the new 
ticket ids.
* There are some other tables you should be concerned with, like Versions, 
Priorities ... and other associated with the ticket system. Also, the 
permissions table. Here is the list of tables:
https://trac.edgewall.org/wiki/TracDev/DatabaseSchema
 * You can ignore: auth_cookie, cache, node_change, revision. As mentioned, 
I'd also ignore the repository table and just add the new repository 
manually.
* Users - depends on the authentication mechanism. It might just be a 
matter of merging htpasswd or htdigest files.

I'd start with a backup of both systems and start working on a script. Feel 
free to post here for advice on the script as it progresses. If you refine 
the script it could be posted as a script on trac-hacks.org, so happy to 
help you get it refined.

The trac-admin hotcopy utility can be used to dump the database on the 
system you are migrating away from.

Which Trac version and which database type? Do you have plugins installed?

- Ryan

-- 
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.