Trac and remote Subversion Repositories
mb
since Ticket #493 has the 0.11 Milestone, I'd like to know its status.
Is somebody
actively working on this?
If so when would it be so far that it can be integrated into trunk. Or
is this feature
dropped because of http://www.meadowy.org/~gotoh/projects/remote-svn-
plugin/wiki.
Because we would like to have this feature very badly. Our subversion
server has to run
on different machine, because of company policy. Right now we use a
workaround with
a read-only svk-mirror-repo, but that has its own problems ...
I'll try the plugin with the svn:// protocol as soon as I have
upgraded our local subversion
clients (python bindings) to 1.3.2 or newer ...
-- Max
Christian Boos
> Hi,
>
> since Ticket #493 has the 0.11 Milestone, I'd like to know its status.
> Is somebody actively working on this?
>
Yes, Shun-Ichi Gotoh ;-)
> If so when would it be so far that it can be integrated into trunk.
> Or is this feature dropped because of
> http://www.meadowy.org/~gotoh/projects/remote-svn-plugin/wiki.
>
Well, we haven't discussed this so far, so maybe this is the occasion.
There are mainly two options:
1. "wontfix" #493 and ask people to use the remote-svn-plugin instead
2. integrate this plugin in core, as an alternative SVN backend
There are several conditions for 2. to happen. First, Shun-Ichi Gotoh
must be OK with that. Then we have to balance the benefits of having
#493 supported out-of-the-box vs. having to maintain another backend.
Right now, given the "experimental" status of the plugin, that balance
doesn't seem to be in favor of the inclusion. And from a look at the
code, this is by no means the fault of Shun-Ichi Gotoh, rather because
of the many bugs and workarounds needed to make the RA/client level
bindings work.
Another argument /against/ 2. is that there could be an alternative
implementation for the feature, by using PySVN, so it wouldn't be fair
to pick one vs. the other. Of course, there's none such alternative
implementation yet, so maybe that's not really a strong argument.
That being said, if there are good progresses on the bindings (maybe for
1.4.4/1.5?) and on the svn-remote-plugin, I'd welcome its integration in
Trac core, but I see that happening in the 0.12 timeframe, or even beyond.
> Because we would like to have this feature very badly. Our subversion
> server has to run
> on different machine, because of company policy. Right now we use a
> workaround with
> a read-only svk-mirror-repo, but that has its own problems ...
>
If you have the opportunity to upgrade the Subversion server software to
1.4.x, maybe a more reliable mirroring can be achieved using svnsync,
and you'll get the exact same revision numbers, author and time infos.
Another option would be to use rsync
(http://svn.haxx.se/users/archive-2003-07/0226.shtml).
-- Christian
Shun-ichi GOTO
2007/2/2, Christian Boos <cb...@neuf.fr>:
> There are several conditions for 2. to happen. First, Shun-Ichi Gotoh
> must be OK with that. Then we have to balance the benefits of having
> #493 supported out-of-the-box vs. having to maintain another backend.
> Right now, given the "experimental" status of the plugin, that balance
> doesn't seem to be in favor of the inclusion. And from a look at the
> code, this is by no means the fault of Shun-Ichi Gotoh, rather because
> of the many bugs and workarounds needed to make the RA/client level
> bindings work.
Of course I'm OK about 2.
However, as cboos mentioned, it is a problem around bugs of binding and
workaround for them. That plugin works with svn 1.3/1.4 but require some dirty
workarounds. It is not good to incorporate them into trac core apparently.
And trac cannot depends on svn 1.5 which is not yet released.
So I think it should be a plugin yet and we should do now is refinement of
the plugin.
# In future? I don't know it.
> If you have the opportunity to upgrade the Subversion server software to
> 1.4.x, maybe a more reliable mirroring can be achieved using svnsync,
> and you'll get the exact same revision numbers, author and time infos.
> Another option would be to use rsync
> (http://svn.haxx.se/users/archive-2003-07/0226.shtml).
There can be a plugin which is exnteded svn.py with a small hook
for automatic mirroring (with some RA calls and svnsync) on every
vc API call. I guess it might be reliable and easy to implement.
--
Shun-ichi GOTO
mb
thanks for your replies. It's great that such a plugin exists in the
first place :)
First I upgraded our clients to 1.4.3, but I couldn't test the plugin
yet, due to
problems upgrading the database. We have some trouble concerning utf8
- latin1
inconsistencies in our database, but this will be fixed soon :)
Afterwards I'll
test the plugin in our environment.
Second, I'd like to give some support, to speed up the improvement of
the plugin.
That is if there are some tasks, that a longtime c++ developer who has
discovered
python just a couple of weeks ago, can tackle.
If so just send me a mail, since IRC is not possible in our corp .. :(
-- Max
On 2 Feb., 18:31, "Shun-ichi GOTO" <shunichi.g...@gmail.com> wrote:
> # Sorry for my slow work to improve that plugin.
>
> 2007/2/2, Christian Boos <c...@neuf.fr>:
Christian Boos
> ...
> Second, I'd like to give some support, to speed up the improvement of
> the plugin.
> That is if there are some tasks, that a longtime c++ developer who has
> discovered
> python just a couple of weeks ago, can tackle.
Well, I don't know exactly the amount of effort you'll be able to
dedicate for this, but if you are well versed in C, probably the most
critical piece of infrastructure that needs to be improved would be the
Subversion bindings themselves. From the last mail of gotoh, I gather
that Subversion 1.5dev already contains a few of the required fixes, but
I'm sure there are more improvements to be made, if only for the speed ;)
Speaking about the bindings, we need to get the svn_diff_file_option_t
type in the bindings, so that we can use blame3 instead of the limited
blame2... This is of interest for both svn_fs.py and svn_ra.py, as blame
functions are in the client layer.
-- Christian
mb
now after having upgraded our MySQL Database (see my other post about
the problems),
I tried to test the plugin. I installed the egg for the plugin in the
global site-packages folder.
I created a trac environment and gave rsvn as repository type and set
the repository dir to
the svn:// URL of our repository.
Repository type [svn]> rsvn
...
Path to repository [/path/to/repos]> svn://pgksvnp1
After that the environment was created, with the following warning.
Repository type rsvn not supported
Ok I can understand that, the plugin is not active at this moment. So
I checked trac.ini and
entered the following:
[components]
tracremotesvn.* = enabled
After navigating to the trac site I received an error saying that the
host wasn't found, in the host
name there some /xbb characters which for me points again to utf8
problems ...
(I can't reproduce the error, short of recreating the environment from
scratch again, which I
would do, if it helps ...)
Well anyway, afterwards I tried to use the http:// protocol, since the
plugin-website said this
protocol was tested. Then I got the following error:
Command failed: unsupported operand type(s) for -: 'long' and
'datetime.datetime'
AFAIK this error means, that the changeset table is at least
incomplete if not empty. So
I tried trac-admin resync, BUT: I received that same error, so I have
no way to fill the table :/
So I have up til now not been able to connect to a remote repository.
Can somebody give me some pointers as to what I have done wrong ...
-- Max
mb
anybody has an idea?
Is this a problem of the new templates? I can't get a
connection to a remote repo working at all, because of the operand
error.
-- Max
On 6 Feb., 09:50, "mb" <maximilian.bernha...@post.rwth-aachen.de>
wrote:
Christian Boos
> Hi,
>
> anybody has an idea?
>
>>
>> now after having upgraded our MySQL Database (see my other post about
>> the problems),
>> protocol was tested. Then I got the following error:
>>
>> Command failed: unsupported operand type(s) for -: 'long' and
>> 'datetime.datetime'
>>
I don't know where this problem happens in the plugin (you should
probably create a ticket in the plugin's Trac), but this looks like a
date column (returned as 'long' by MySQL) being manipulated together
with a datetime object. Most probably the plugin is not 0.11 compatible.
-- Christian
Shun-ichi GOTO
> anybody has an idea?
>
> Is this a problem of the new templates? I can't get a
> connection to a remote repo working at all, because of the operand
> error.
Trac-remote-plugin is not tested with MySQL at all.
I've tested with SQLite + Trac 0.10.x (time as double)
and 0.11 (time as datetime).
However I can't try with MySQL because I don't have environment.
Do you succeed running Trac on that machine with *LOCAL* repo + MySQL?
At least, tell me what verseion (or revision) of trac are you using.
Anyway, there's some in my mind around error of op between datetime and long.
Tell me your environment.
BTW, Can you get backtrace on that error?
And you'd better to make a ticket about this with some more informations,
not talking on this list.
## http://www.meadowy.org/~gotoh/projects/remote-svn-plugin/newticket
--
Shun-ichi GOTO
mb
yes I can use trac with a local (svk mirrored) repo. It all works like
a charm,
but the revisions are between the remote and the local repo are not in
sync.
That is *why* I'd like to access the remote repo directly.
Yes I will gather some more Information and create a ticket. BTW the
time
field in the revision table in MySQL is of type int(11).
Thanks for your help
-- Max
On 13 Feb., 11:06, "Shun-ichi GOTO" <shunichi.g...@gmail.com> wrote:
> 2007/2/13, mb <maximilian.bernha...@post.rwth-aachen.de>:
mb
stupid me. I used version 0.2 of the plugin. The Bug had already been
filed and was fixed in Rev26.
Sorry for the noise.
-- Max
On 13 Feb., 14:29, "mb" <maximilian.bernha...@post.rwth-aachen.de>
wrote: