Single Trac Ticket System with Multiple Repositories
Sumith
QUESTION IN 1 LINE: How to specify 'direct-svn-fs' for repository
type?
DESCRIPTION:
I have used Trac for couple of months and love it a lot. Generally, we
configure Trac and its SVN repository which works fine.
Now I have a requirement of sharing a single Trac Wiki with multiple
repositories. By doing this what I am expecting is to "share"
Ticketing System, Wiki Pages while individual project groups having
their own code repository, access control, timeline (for changesets).
By searching around for couple of days I realized that we can achieve
this by having a 'database' on shared configuration and 'repository-
dir' on project specific configuration.
However, by having this I get "TracError: The 'repository_dir' has
changed, a 'trac-admin resync' operation is needed." every time I swap
the project. By resynchronizing it works back.
Therefore now I want NOT to use database for repository access. In
other works to disable 'caching' for repository access.
I saw at few places (http://trac.edgewall.org/browser/branches/cboos-
dev/vc-refactoring/trac/versioncontrol/svn_fs.py?rev=2464) that we can
achieve this by specifying repository type as 'direct-svn-fs'. When I
do that it says: TracError: Unsupported version control system "direct-
svn-fs".
What's the possible solution for me.
Thanks in advance!
Sumith
Christian Boos
> Dear All,
>
> QUESTION IN 1 LINE: How to specify 'direct-svn-fs' for repository
> type?
>
Answer in one line: you can't ;-)
> DESCRIPTION:
> I have used Trac for couple of months and love it a lot. Generally, we
> configure Trac and its SVN repository which works fine.
>
> Now I have a requirement of sharing a single Trac Wiki with multiple
> repositories. By doing this what I am expecting is to "share"
> Ticketing System, Wiki Pages while individual project groups having
> their own code repository, access control, timeline (for changesets).
>
> By searching around for couple of days I realized that we can achieve
> this by having a 'database' on shared configuration and 'repository-
> dir' on project specific configuration.
>
That's an interesting approach, as it's not really a supported way of
running Trac, but it might work.
> However, by having this I get "TracError: The 'repository_dir' has
> changed, a 'trac-admin resync' operation is needed." every time I swap
> the project. By resynchronizing it works back.
>
>
Proper support for multiple repository will only be there in 0.12, in
the meantime there's the assumption that to one Trac environment
correspond one repository.
> Therefore now I want NOT to use database for repository access. In
> other works to disable 'caching' for repository access.
>
> I saw at few places (http://trac.edgewall.org/browser/branches/cboos-
> dev/vc-refactoring/trac/versioncontrol/svn_fs.py?rev=2464) that we can
> achieve this by specifying repository type as 'direct-svn-fs'. When I
> do that it says: TracError: Unsupported version control system "direct-
> svn-fs".
>
> What's the possible solution for me.
>
That would be a workaround that /might/ work, I've never tried, so
you'll be on your own.
The 'direct-svn-fs' setting is no longer current, but I can make a patch
to re-enable it. Do you need it for trunk or for 0.10 ?
-- Christian
Sumith
Thanks for quick reply.
>
> Answer in one line: you can't ;-)
:(
>
> Proper support for multiple repository will only be there in 0.12, in
> the meantime there's the assumption that to one Trac environment
> correspond one repository.
Can I start to use 0.12? Is there any place to get it? Any ideas how
stable will it be by now? When Trac plan to release it.
>
> That would be a workaround that /might/ work, I've never tried, so
> you'll be on your own.
> The 'direct-svn-fs' setting is no longer current, but I can make a patch
> to re-enable it. Do you need it for trunk or for 0.10 ?
>
Yes, please! I am using 0.10.3.
Regards,
Sumith
Noah Kantrowitz
> Dear Chistian,
>
> Thanks for quick reply.
>
>
>> Answer in one line: you can't ;-)
>>
> :(
>
>
>> Proper support for multiple repository will only be there in 0.12, in
>> the meantime there's the assumption that to one Trac environment
>> correspond one repository.
>>
>
> Can I start to use 0.12? Is there any place to get it? Any ideas how
> stable will it be by now? When Trac plan to release it.
>
about a year ....
--Noah
සුමිත් ගමගේ
> > Can I start to use 0.12? Is there any place to get it? Any ideas how
> > stable will it be by now? When Trac plan to release it.
> >
> Considering 0.11dev is what is currently being developed, check back in
> about a year ....
Oops! I cannot wait years at all. Then the only solution seems to be
the patch suggested by Christian. I am waiting for it.
Christian, you are going to be the god of mine :)
Sumith
Christian Boos
> On 5/29/07, Noah Kantrowitz <kan...@rpi.edu> wrote:
>
>>> Can I start to use 0.12? Is there any place to get it? Any ideas how
>>> stable will it be by now? When Trac plan to release it.
>>>
>>>
>> Considering 0.11dev is what is currently being developed, check back in
>> about a year ....
>>
>
> Oops! I cannot wait years at all. Then the only solution seems to be
> the patch suggested by Christian. I am waiting for it.
>
The patch was quite simple, it's only about skipping the use of the
CachedRepository. I'd be interested to hear if it works fully for you,
as I only did some superficial testing. If so, I'll apply it.
One thing that will /not/ work in your "experimental" setup are
changeset:, source: and log: links, unless you use intertrac links
specifying which env and therefore which repository you're targeting.
I wonder also if this setup (several trac envs using the same db)
wouldn't be prone to new exotic cases of db lock ups ;-)
-- Christian
Sumith
> The patch was quite simple, it's only about skipping the use of the
> CachedRepository. I'd be interested to hear if it works fully for you,
> as I only did some superficial testing. If so, I'll apply it.
>
> 1KDownload
Now I am getting:
Traceback (most recent call last):
File "C:\Python24\Lib\site-packages\trac\web\main.py", line 387, in
dispatch_request
dispatcher.dispatch(req)
File "C:\Python24\Lib\site-packages\trac\web\main.py", line 191, in
dispatch
chosen_handler = self._pre_process_request(req, chosen_handler)
File "C:\Python24\Lib\site-packages\trac\web\main.py", line 263, in
_pre_process_request
chosen_handler = f.pre_process_request(req, chosen_handler)
File "C:\Python24\lib\site-packages\trac\versioncontrol\api.py",
line 73, in pre_process_request
self.get_repository(req.authname) # triggers a sync if applicable
File "C:\Python24\lib\site-packages\trac\versioncontrol\api.py",
line 91, in get_repository
raise TracError('Unsupported version control system "%s"'
TracError: Unsupported version control system "direct-svn-fs"
It seems we have to define direct-svn-fs as an acceptable SVN
repository type somewhere.
Sorry, I am not that good @ Python yet :(.
Regards,
Sumith
Christian Boos
> ...
> TracError: Unsupported version control system "direct-svn-fs"
>
> It seems we have to define direct-svn-fs as an acceptable SVN
> repository type somewhere.
>
> Sorry, I am not that good @ Python yet :(.
>
Use direct-svnfs, not direct-svn-fs (as "svnfs" was already a valid name).
-- Christian
Sumith
> Sumith wrote:
> > TracError: Unsupported version control system "direct-svn-fs"
>
>
This suggestion too did not works it said "direct-svnfs" is not
supported. So I simply removed if conditional part on your patch and
used
crepos = repos
directly and in trac.ini I used "svn"
repository_type = svn.
Now it works fine.
As you have already mentioned in one of the previous post to this
thread changeset is not working:
Traceback (most recent call last):
File "D:\Python24\Lib\site-packages\trac\web\main.py", line 387, in
dispatch_request
dispatcher.dispatch(req)
File "D:\Python24\Lib\site-packages\trac\web\main.py", line 237, in
dispatch
resp = chosen_handler.process_request(req)
File "D:\Python24\Lib\site-packages\trac\versioncontrol\web_ui
\changeset.py", line 254, in process_request
diff_args, diff_options)
File "D:\Python24\Lib\site-packages\trac\versioncontrol\web_ui
\changeset.py", line 313, in _render_html
for name, value, wikiflag, htmlclass in chgset.get_properties():
TypeError: iteration over non-sequence
Regards,
Sumith
Paul Cuda
Christian Boos
> On May 30, 2:33 pm, Christian Boos <c...@neuf.fr> wrote:
>
>> Sumith wrote:
>>
>>> TracError: Unsupported version control system "direct-svn-fs"
>>>
>> Use direct-svnfs, not direct-svn-fs (as "svnfs" was already a valid name).
>>
>>
>
> This suggestion too did not works it said "direct-svnfs" is not
> supported.
>
Strange, it worked for me ;-)
Can anyone else please try the patch, use repository_type = direct-svnfs
and make some change on the fly to the repository_dir?
> ...
> for name, value, wikiflag, htmlclass in chgset.get_properties():
> TypeError: iteration over non-sequence
>
That's a different bug: you need the following fix:
Index: trac/versioncontrol/api.py
===================================================================
--- trac/versioncontrol/api.py (revision 5545)
+++ trac/versioncontrol/api.py (working copy)
@@ -409,6 +409,7 @@
Warning: API will be improved (see #1601 and #2545).
"""
+ return []
def get_changes(self):
"""Generator that produces a tuple for every change in the
changeset
-- Christian
Sumith
Thanks for all supportive communication on this issue so far.
On May 30, 5:52 pm, Christian Boos <c...@neuf.fr> wrote:
>
> > This suggestion too did not works it said "direct-svnfs" is not
> > supported.
>
> Strange, it worked for me ;-)
It seems we are not referring to the same code line. I am using Trac
0.10.3 release for Windows. I guess it is http://trac.edgewall.org/browser/tags/trac-0.10.3
(I am not sure).
D:\Python24\Scripts>trac-admin.py --version
Trac Admin Console 0.10.3
I would like to try with the same code-line you use in my experiment.
So I will have less trouble in fixing the issues.
Are you using http://trac.edgewall.org/browser/branches/0.10-stable or
something else?
>
> Index: trac/versioncontrol/api.py
> ===================================================================
> --- trac/versioncontrol/api.py (revision 5545)
> +++ trac/versioncontrol/api.py (working copy)
> @@ -409,6 +409,7 @@
>
> Warning: API will be improved (see #1601 and #2545).
> """
> + return []
>
> def get_changes(self):
> """Generator that produces a tuple for every change in the
> changeset
>
I was bit confused how to apply this patch in my code revision. It
seems you have added blank return statement to the get_property()
function. I did the same in my code, but still no luck.
Best regards,
Sumith
Christian Boos
Not just "return", but "return []" ;-)
Well, for improved clarity, I updated the original patch to contain both
changes, made on latest of 0.10-stable.
But that patch will also work on a clean 0.10.3 checkout, as you can see
in the following:
$ patch -p0 < ../../branches/0.10-stable/direct-svnfs-0.10.5dev.diff
(Stripping trailing CRs from patch.)
patching file trac/versioncontrol/api.py
Hunk #1 succeeded at 386 (offset -23 lines).
(Stripping trailing CRs from patch.)
patching file trac/versioncontrol/svn_fs.py
Hunk #1 succeeded at 247 (offset 25 lines).
Hunk #2 succeeded at 258 (offset 25 lines).
I verified this patched 0.10.3 Trac, using the following settings:
[trac]
...
#repository_dir = C:/Workspace/local/svn/empty
#repository_dir = C:/Workspace/local/svn/trac-svnrepos
#repository_dir = C:/Workspace/local/svn/trac-svnrepos/trunk/src-copy
repository_dir = C:/Workspace/local/svn/trac-vc
#repository_type = svn
repository_type = direct-svnfs
and switching back and forth between the different repository_dir
entries while the server was running worked fine, as expected.
But be aware that 0.10.3 is not the latest "stable" version and you
should be using at least 0.10.4, if not 0.10.5dev.
-- Christian
Sumith
Wow! It's really ammazing!!
Everything work exactly as expected so far in my test bed by applying
your patch on http://svn.edgewall.com/repos/trac/branches/0.10-stable/.
I will let you know my performance with production deployment with
next week (hopefully).
Thanks a lot for your continous support on this issue.
Regards,
Sumith
Sumith
Thanks for the help so far. It works fine so far.
Now I am having a problem of sharing the attachment across Wikis.
Trac by default store attachments in "attachments" directory within
the project. Therefore when I attach a file from one project, it is
not accessible from other.
There are two possible solutions I see:
1. Add new directive to [attachments] section in trac.ini. Then I can
define that directive inside the common configuration file and share
among all projects. Sorry, I cannot develop the patch myself rather
than begging someone :(
2. Create a link from one Trac project directory to other. Then what I
have is a link names 'attachments' instead of a directory.
Unfortunately, this did not worked (at least for me on Windows XP).
Will someone be able to give me a patch to enable this.
Or else is there any other better way to handle this?
Please bare with me. I am requesting too much :(
Regards,
Sumith
Christian Boos
> Dear Christian & All,
>
> Thanks for the help so far. It works fine so far.
>
> Now I am having a problem of sharing the attachment across Wikis.
>
> Trac by default store attachments in "attachments" directory within
> the project. Therefore when I attach a file from one project, it is
> not accessible from other.
>
> There are two possible solutions I see:
>
> 1. Add new directive to [attachments] section in trac.ini. Then I can
> define that directive inside the common configuration file and share
> among all projects. Sorry, I cannot develop the patch myself rather
> than begging someone :(
>
Probably not the way to go.
> 2. Create a link from one Trac project directory to other. Then what I
> have is a link names 'attachments' instead of a directory.
> Unfortunately, this did not worked (at least for me on Windows XP).
> Will someone be able to give me a patch to enable this.
>
That should work flawlessly on Unix.
For Windows NTFS, I think you have tools that allow you to create
equivalents to symbolic links (google for "junctions").
-- Christian
Roo
> That should work flawlessly on Unix.
> For Windows NTFS, I think you have tools that allow you to create
> equivalents to symbolic links (google for "junctions").
>
> -- Christian
Or have a look at Microsoft Windows "Services for Unix" (SFU), it is now free :)
I have not had a chance to evaluate it yet, but it apparently supports
hard and soft symbolic links as well as many other things. It also
provides a Korn and C shell apparently... ROFL!
See: http://technet.microsoft.com/en-us/library/44E1270D-FA93-6772-E030-D81ADC0DB149.aspx
Cheers
Sumith
> On 01/06/07, Christian Boos <c...@neuf.fr> wrote:
>
> > That should work flawlessly on Unix.
> > For Windows NTFS, I think you have tools that allow you to create
> > equivalents to symbolic links (google for "junctions").
>
>
Dear Christian & Roo,
Thanks for both your suggestions. I tried Christian's suggestion & it
worked for me.
Regards,
Sumith