Mailing List Archive

fsfs repository replacement
My BDB-based Subversion repositories have twice in a month displayed an
unpleasant tendency to blow up. Following the most recent episode, I
rebuilt my repository from a slightly outdated backup, while switching
to fsfs.

Trac's timeline is now out of sync with my repository (found at the same
path as the old one). Several of Trac's displayed changesets no longer
exist, since they weren't in my Subversion backup, and the commits made
since the repository rebuild don't appear in the timeline. So, two
questions:

Is Trac dependent on Subversion's BDB backend, or should it work with an
fsfs backend?

If Trac will work with fsfs, what do I have to do to make it aware of
the new repository, while preserving tickets and other local
modifications?

Thanks,

-nat
fsfs repository replacement [ In reply to ]
its been a while since i looked at a trac source.. but here goes ;-)

trac's working on an svn repository/fs layer, and shouldn't care about
the underlying storage.

you'll need to kill your revisions table, and trac should automatically
reindex it the next time its used.

its not doing so now because it latest revision number stored is greater
than the one in the repo, so it thinks it has nothing to do.

cheers,

-kapil

Nathaniel Irons wrote:
> My BDB-based Subversion repositories have twice in a month displayed an
> unpleasant tendency to blow up. Following the most recent episode, I
> rebuilt my repository from a slightly outdated backup, while switching
> to fsfs.
>
> Trac's timeline is now out of sync with my repository (found at the same
> path as the old one). Several of Trac's displayed changesets no longer
> exist, since they weren't in my Subversion backup, and the commits made
> since the repository rebuild don't appear in the timeline. So, two
> questions:
>
> Is Trac dependent on Subversion's BDB backend, or should it work with an
> fsfs backend?
>
> If Trac will work with fsfs, what do I have to do to make it aware of
> the new repository, while preserving tickets and other local
> modifications?
>
> Thanks,
>
> -nat
> _______________________________________________
> Trac mailing list
> Trac@lists.edgewall.com
> http://lists.edgewall.com/mailman/listinfo/trac
>
fsfs repository replacement [ In reply to ]
I posted a SQL query to do this a while back - see:

http://lists.edgewall.com/archive/trac/2004-June/000409.html

There's a 'trac-admin resync' command to do this in the trunk, but it =
didn't make it into 0.7-table.

Ian.

-----Original Message-----
From: trac-bounces@lists.edgewall.com =
[mailto:trac-bounces@lists.edgewall.com] On Behalf Of Nathaniel Irons
Sent: 25 August 2004 01:29
To: trac@lists.edgewall.com
Subject: [Trac] fsfs repository replacement


My BDB-based Subversion repositories have twice in a month displayed an =
unpleasant tendency to blow up. Following the most recent episode, I =
rebuilt my repository from a slightly outdated backup, while switching =
to fsfs.

Trac's timeline is now out of sync with my repository (found at the same =
path as the old one). Several of Trac's displayed changesets no longer =
exist, since they weren't in my Subversion backup, and the commits made =
since the repository rebuild don't appear in the timeline. So, two
questions:

Is Trac dependent on Subversion's BDB backend, or should it work with an =
fsfs backend?

If Trac will work with fsfs, what do I have to do to make it aware of =
the new repository, while preserving tickets and other local =
modifications?

Thanks,

-nat
_______________________________________________
Trac mailing list
Trac@lists.edgewall.com http://lists.edgewall.com/mailman/listinfo/trac

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.742 / Virus Database: 495 - Release Date: 19/08/2004
=20
fsfs repository replacement [ In reply to ]
On Wed, Aug 25, 2004 at 08:10:33AM +0100, Ian Leader wrote:

> I posted a SQL query to do this a while back - see:
>
> http://lists.edgewall.com/archive/trac/2004-June/000409.html

Thanks, that works nicely.

An unsought benefit to switching to fsfs is that I no longer have to
give the www user write access to my subversion repository. I lost a
few days on this but I'm happy with the outcome.

-nat