Edgewall Software
Modify

Opened 20 years ago

Closed 9 years ago

Last modified 16 months ago

#493 closed enhancement (wontfix)

Use trac with a remote Subversion repository

Reported by: radix at twistedmatrix.com Owned by: Christian Boos
Priority: high Milestone:
Component: version control Version: 0.9.2
Severity: major Keywords: subversion svn remote repository svk
Cc: yuangang28@…, nslater@…, oetiker@…, marshall@…, slith76@…, jwin1@…, azrael@…, mr0winky@…, caio1982@…, edgewall.cjy@…, anarcat@…, chris@…, chris.a.williams@…, jp@…, scott@…, tdussa@…, heikki.lampen@…, climaxius@…, felix.schwarz@…, trac.edgewall.org@…, martin.marcher@…, soloturn@…, imanuel.scholz@…, jyrki.muukkonen@…, sergei@…, sloukam@…, dstaple@…, buckett@…, jasonm23@…, ryanmccue@…, jcalcote@…, mdecoffe@…, a_baranenko@…, jan-trac@…, termim@…, dl9pf@…, richard@…, robert@…, mike@…, andy@…, bbdakraxor@…, linux-madagascar@…, jae+trac@…, crazedfred@…, chris.tandiono@…, olemis+trac@…, mpotter@…, cd@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description (last modified by Christian Boos)

Currently Trac needs to have a direct (read-only) access to the Subversion repository. It's not yet possible to simply specify an URL to a remote repository.

Alternatives

Shun-ichi Goto wrote an alternative backend for Subversion which uses the svn_ra layer, see: http://www.meadowy.org/~gotoh/hg/remote-svn-plugin

Otherwise, it's quite easy to mirror a remote repository using svnsync and have Trac access the local copy.

Attachments (0)

Change History (186)

comment:1 by mrowe@…, 20 years ago

Severity: normalenhancement

At present Subversion's Python bindings do not support the more-generic "repository access layer" that would facilitate accessing file://, http:// and svn:// repositories. Adding support for remote repositories to Trac will be difficult until this situation is remedied.

comment:2 by daniel, 20 years ago

As Mark pointed out, this is indeed the reason for above mentioned stink.

Whenever there's an official way to us the RA layer, Trac will utilize it.

comment:3 by anonymous, 20 years ago

This is understandably difficult. However, do ant trac'ers have recommendations for how to do do fine grained access control for users coming through trac? I'm currently using subversions apache module to control which users have read and write access to content via AuthzSVNAccessFile. Since trac is using the server bindings and not going through HTTP as a client, it is bypassing my access control layer. Does any one know how to do svn access control at a lower level???

I'll take this up on the svn lists too.

comment:4 by Christopher Lenz, 19 years ago

Summary: Use trac with a REMOTE Subversion repositoryUse trac with a remote Subversion repository

comment:5 by Marc Sutton, 19 years ago

Subversion 1.2 has just been released and they've flattened the remote access API so SWIG can access it (and python bindings can be produced).

Is that all that's required to get trac to use a remote repository?

comment:6 by Christopher Lenz, 19 years ago

Description: modified (diff)

I've experimented with this, but unfortunately the SWIG bindings for svn_ra didn't seem to be completely usable.

For example, svn_ra_stat (IIRC) should return a dirent object of some kind, but it expects a pointer to a struct. Apparently the mapping from C to python isn't quite worked out yet for that layer.

comment:7 by Juanma Barranquero, 19 years ago

[...] Subversion 1.2 has just been released [...]

Well, Subversion 1.2 has not yet been released, unless you count release candidates as full releases. Let's not spread wrong information, please.

comment:8 by eric@…, 19 years ago

1.2 has been released now… any improvement on this situation?

comment:9 by anonymous, 19 years ago

Related to fine grained permissions question asked in this topic:

http://projects.edgewall.com/trac/wiki/FineGrainedPermissions

comment:10 by jwt, 19 years ago

Component: generaltrac-admin
Keywords: repository svk added
Owner: changed from Jonas Borgström to daniel
Version: 0.70.8.3

I have successfully used http://svk.elixus.org/ for mirroring a remote repository (to a local trac-server). Obviously this is not always desirable.

Any status-update on this issue yet ?

comment:11 by anonymous, 19 years ago

Cc: vyt@… added

comment:12 by marshall@…, 18 years ago

Cc: marshall@… added

comment:13 by anonymous, 18 years ago

Cc: slith76@… added

comment:14 by Christopher Lenz, 18 years ago

Component: trac-adminversion control
Owner: changed from daniel to Christopher Lenz

comment:15 by anonymous, 18 years ago

Cc: jwin1@… added

comment:16 by anonymous, 18 years ago

Cc: vyt@vzljot.ru, marshall@exclupen.com, slith76@gmail.com,jwin1@web.de → vyt@vzljot.ru, marshall@exclupen.com, slith76@gmail.com, jwin1@web.de

comment:17 by Tobi Oetiker <oetiker@…>, 18 years ago

Cc: oetiker@… added
Version: 0.8.30.9b2

When I try using svn://svn....../repo as a repository path, I end up with a nice error message:

Assertion failed: is_canonical (base, blen), file subversion/libsvn_subr/path.c, line 114

I am using svn 1.2.1 with trac 0.9b2

any progress on remote repository support ?

comment:18 by jwin1@…, 18 years ago

I really want to promote using trac here with our development, but our 'server-folks' (sadly) just aren't open-minded enough to keep trac and svn on one machine, not speaking of all political difficulties…

This is really an important one for us.

comment:19 by Matthew Good, 18 years ago

Well, I think that it will save your "server-folks" some work to keep the two on the same box, since it makes it easier to set up things like the authentication that should be the same between them. If the SVN repository uses the FSFS backend (highly recommended), you can run Trac with read-only access to the repository. If that's still not sufficient, you should be able to share the SVN repository read-only via NFS to the Trac server.

comment:20 by anonymous, 18 years ago

Any experienced IT administrator knows that keeping multiple services on one box does not "save work". This is the single reason why we cannot adopt Trac for any real project in our organization. We have an established SVN repository, processes, and security policy and there is no way we could install Trac on the SVN server. The SVN server is considered security and mission critical.

If there would be a way to somehow relay authorization from the user's desktop to the SVN server through Trac, that would be perfect. This way we could set up Trac without having to let our IT department set it up (which would take months to actually happen). We could update to a new release and apply patches whenever we need to. Currently, we cannot, since setting up Trac requires all-permissive access to the SVN repository and that means it would have to be administered by the IT guys. If Trac could offload all real authentication and access control to SVN, our IT would be happy.

Anyway, just the possibility to access a remote SVN repository is needed for our IT to even consider setting up a Trac server.

comment:21 by jwin, 18 years ago

regardless of the status of the swig-python bindings, if I want to test the svn_ra access, is

trunk/trac/versioncontrol/tests

the right place to look for modifying to use svn_ra access ?

Has anyone done this recently ?

comment:22 by jwin, 18 years ago

how about using a Python-extension written in C the C-Api for svn_ra should work

comment:23 by jw, 18 years ago

svn 1.3rc7

  • new public APIs:
    • new transfer progress callback for DAV (r15948)
    • svn_ra_initialize(), svn_client_open_ra_session()
    • svn_fs_closest_copy(), svn_fs_type()
    • several rev'd APIs, see doxygen docs
  • SWIG bindings: No more compile-time or runtime SWIG dependencies
    • SWIG/python bindings:
      • automatic memory management: APIs no longer require pool

comment:24 by anonymous, 18 years ago

Version: 0.9b20.9.2

comment:25 by Mitch, 18 years ago

Any progress on this? I'd love to use this feature.

comment:26 by imp <trac@…>, 18 years ago

Cc: trac@… added

comment:27 by anonymous, 18 years ago

Cc: anderson@… added

comment:28 by anonymous, 18 years ago

Cc: azrael@… added

comment:29 by anonymous, 18 years ago

Cc: cbassham@… added

comment:30 by anonymous, 18 years ago

Milestone: 0.9.5

comment:31 by Christopher Lenz, 18 years ago

Milestone: 0.9.5

WTF?

comment:32 by anonymous, 18 years ago

Cc: mr0winky@… added

Whats the eta on this feature? We have been using trac for about 1 year and would like to decouple Trac from the svn repository because we do not wish to give out mass accounts to the machine hosting our repo, for obvious security/stability reasons.

comment:33 by anonymous, 18 years ago

Cc: trac-trac@… added

comment:34 by Emmanuel Blot, 18 years ago

#2828 has been marked as a duplicate.

comment:35 by caio1982, 18 years ago

Any progress on making it happen? Does anyone above got some err… "hack" that fully works? Mirroring data using SVK or even DRBD (!) is not a real option and NFS is… well, you know.

comment:36 by anonymous, 18 years ago

Cc: caio1982@… added

comment:37 by anonymous, 18 years ago

pysvn seems to have support for accessing remote repositories. And these bindings looks a lot more "active" too.

comment:38 by Christian Boos, 18 years ago

Milestone: 0.11
Owner: changed from Christopher Lenz to Christian Boos
Priority: normallow

I've noticed the pysvn suggestion when it was made. This, combined with the VcRefactoring#NewRepositoryCache changes, would make it practical to work with remote subversion repositories, as remote requests would only have to be done for doing changeset synchronizations.

comment:39 by anonymous, 18 years ago

Cc: edgewall.cjy@… added

comment:40 by anonymous, 18 years ago

I want to set up Trac for a SourceForge project, but I can't until this feature is added. I hope it happens soon.

comment:41 by Barry Scott, 18 years ago

pysvn indeed can access remote repos. Is there anything missing from pysvn API that would prevent you using it to solve this problem? (Apart from the pain of changing from svn bindings to pysvn that is!)

Barry - pysvn author

comment:42 by anonymous, 18 years ago

Cc: anarcat@… added

comment:43 by anonymous, 18 years ago

Cc: stevej@… added

comment:44 by caio1982, 18 years ago

Priority: lownormal

I think it's a quite important feature that would make Trac even more flexible so it's not that good change this ticket's priority to "low" instead of "normal". Workarounds or extensions are acceptable but aren't the best solution, IMHO.

comment:45 by anonymous, 18 years ago

Lack of this feature is the main reason why my new employer's development department doesn't use Trac (a pretty big international company). I've used Trac on the previous job with great success and I'm very sad I can't use it now.

comment:46 by anonymous, 18 years ago

We are a small team in a big company evaluating Trac. This single issue is the reason why we won't use it companywide.

comment:47 by Manuzhai, 18 years ago

Cc: manuzhai@… added

comment:48 by anonymous, 18 years ago

Cc: chris.a.williams@… added

comment:49 by anonymous, 18 years ago

Cc: tim_gould@… added

comment:50 by anonymous, 18 years ago

Cc: jp@… added

comment:51 by anonymous, 18 years ago

Cc: scott@… added

comment:52 by anonymous, 18 years ago

Cc: tdussa@… added

comment:53 by anonymous, 18 years ago

Cc: heikki.lampen@… added

comment:54 by anonymous, 18 years ago

Cc: climaxius@… added

comment:55 by anonymous, 18 years ago

Priority: normalhighest

comment:56 by Matthew Good, 18 years ago

Priority: highestnormal

Feel free to bump up the priority if you're volunteering to implement it. Otherwise you'll need to be patient.

comment:57 by anonymous, 18 years ago

Cc: felix.schwarz@… added

comment:58 by anonymous, 18 years ago

Cc: trac.edgewall.org@… added

comment:59 by anonymous, 18 years ago

Cc: trac.edgewall.org@… added

comment:60 by trac@…, 18 years ago

In terms of implementing this, I was thinking it would be easy enough to write a new version control module (i.e. svn_pysvn) that uses pysvn instead of subersion's python bindings.

Does that make sense ? Are there any pitfalls to doing it this way ?

comment:61 by Christian Boos, 18 years ago

This was already acknowledged as being a good idea. See comment:38. The point of waiting for the upcoming refactoring would be to have much less work to do in order to write this new backend, as most of the operations will be done on the cache, and basically only the synchronisation of new changes will have to be backend-specific (at least that's the plan).

Nevertheless, I you feel like doing so, it would be perfectly possible to write a pysvn backend right now for milestone:0.10.

comment:62 by anonymous, 18 years ago

Cc: rnc000@… added

comment:63 by lists01@…, 18 years ago

just a "me too" re: support for remote SVN repositories. we want to use trac but our sysadmin team already has a stand-alone SVN server set up.

the "on-the-same-box" requirement may be fine for small teams (or teams with that kind of independence), but in large organizations where there is a separation of responsibilities this requirement can be a show-stopper.

comment:64 by Christian Boos, 18 years ago

Severity: normalmajor

Among the possible workarounds, there's also svnsync, which is a new tool part of Subversion 1.4. It allows to easily replicate repositories, from URL / to URL, which gives you a great deal of flexibility.

For example, you can set up a post-commit hook on the central repository that will trigger the replication to a slave repository on the server where you run Trac. Alternatively, on that Trac host, you can periodically call svnsync which will pull new revisions from the central repository.

I've tested that tool with 1.4.0rc5, and it works fine. Of course you could have done the above using svk mirror, but svnsync is more straightforward to install and use.

comment:65 by anonymous, 18 years ago

Cc: cbassham@… removed

comment:66 by anonymous, 18 years ago

Cc: anderson@… removed

comment:67 by Shun-ichi Goto <shunichi.goto@…>, 18 years ago

I guess there is a way to access remote repository by using standard python binding of subversion 1.4 like svnsync (written by C) does. It may require smaller change than implementing pysvn backend. Of course, it will have limitation that both trac side and remote server side need svn 1.4 or later.

comment:68 by anonymous, 17 years ago

Cc: martin.marcher@… added

comment:69 by anonymous, 17 years ago

Cc: chris@… added

comment:70 by chris@…, 17 years ago

Any news on this? I'm wanting to use Trac for a SourceForge project but cannot install it on the server since I don't have file:// access to the repository. I could mirror the repository but if I'm going to do that I might as well just move my repository to my VDS which I rather not do :(

We use Trac at work and are extremely happy with it. We found it's made our lives impressively easier and tend to spend a lot of time reloadng the timeline page. I think having remote SVN capabilities would sell this to the masses 100%.

comment:71 by sik0fewl, 17 years ago

Cc: rflegel@… added

Another "me too." Has there been any recent progress on this ticket? The suggestion by Shun-ichi Goto seems like it will work well, at least for subversion 1.4 and greater.

comment:72 by Shun-ichi Goto <shunichi.goto@…>, 17 years ago

I'm working for a week to implement this backend using Subversion RA API with standard python binding. Now the code, called svn_ra, is implemented as plugin and tested to have same behaviour and result with svn_fs. It seems to work for some small project but not yet tested with big one. So it is alpha state. There are many things to be implemented and improved, especially speed up of resync.

I'm placed it in public. You can try it if you are interested in.
http://www.meadowy.org/~gotoh/projects/remote-svn-plugin/wiki
But don't forget that it should not be used for actual project yet. I'll continue to improve it.

BTW, I've also implemented with pysvn before using RA. It is very costfull because it uses client API (not RA) and client API makes session every API call. I found it is intended to replace client program (wc operation) then I gave up using it.

comment:73 by Christian Boos, 17 years ago

Milestone: 0.110.12

See the mailing list thread starting with this mail.

We'll see in milestone:0.12 if we will integrate Shun-ichi Goto's svn_ra.py backend in Trac core, or not. In the meantime, please give a try to his remove-svn-plugin and help him improving it.

comment:74 by anonymous, 17 years ago

Cc: soloturn@… added

comment:75 by lists@…, 17 years ago

Cc: lists@… added

comment:76 by anonymous, 17 years ago

Cc: rnc000@… removed

removed my email from CC

in reply to:  73 comment:77 by Dan <trac@…>, 17 years ago

Replying to cboos:

See the mailing list thread starting with this mail.

We'll see in milestone:0.12 if we will integrate Shun-ichi Goto's svn_ra.py backend in Trac core, or not. In the meantime, please give a try to his remove-svn-plugin and help him improving it.

I started using it, but I have not yet understood how to configure/update it with user authentication options. This is a stumbling point for me, because the remote repository(s) I want to target are not visible via anonymous access. The standard bindings want to use a callback function for this, but they don't seem to accept a Python function for this purpose. I'm investigating SWIG in general, but so far haven't found a way to implement this capability. (The document I read indicated this kind of callback is not supported.)

I took a look at pysvn, which seems that it would be very simple to add in the authentication callback function(s), although I haven't tried it yet. However, the Trac remote backend using pysvn is apparently a "dead end", as indicated above in comment:72 .

By the way, much thanks to Shun-ichi Goto for getting this feature going! It will be extremely useful IMHO.

comment:78 by anonymous, 17 years ago

Cc: imanuel.scholz@… added

comment:79 by anonymous, 17 years ago

Cc: nslater@… added

comment:80 by anonymous, 17 years ago

Cc: tim_gould@… removed

comment:81 by anonymous, 17 years ago

Cc: jyrki.muukkonen@… added

comment:82 by anonymous, 17 years ago

Cc: dewey@… added

comment:83 by anonymous, 17 years ago

Cc: sergei@… added

comment:84 by anonymous, 17 years ago

Cc: thomas.subera@… added

comment:85 by anonymous, 17 years ago

Cc: sloukam@… added

comment:86 by anonymous, 17 years ago

Cc: dstaple@… added

comment:87 by anonymous, 17 years ago

Cc: buckett@… added

comment:88 by anonymous, 17 years ago

Cc: jasonm23@… added

comment:89 by anonymous, 17 years ago

Cc: matthew.block@… added

comment:90 by ryanmccue@…, 17 years ago

Cc: ryanmccue@… added

This is the one and only reason stopping me from using Trac. I've used Trac on previous projects and it rocks, but as my host doesn't support SVN repositories, I'm keeping them on Google Code and SourceForge.

comment:91 by anonymous, 17 years ago

Cc: stevej@… removed

comment:92 by anonymous, 17 years ago

Another me too. This feature would help me for some sourceforge projects and also in my company.

comment:93 by anonymous, 17 years ago

Cc: jcalcote@… added

Adding myself to the CC list - we need remote SVN access - I'm going to try the one that's been advertised on this ticket, but I'm worried about the alpha state of it. Luckily, all of our repositories have anonymous access, so we don't need svn auth for trac's interface. I wish you folks would up the priority on this one - I'd love to see it integrated in Milestone 0.11. Thanks for the great tool anyway!

in reply to:  93 comment:94 by anonymous, 17 years ago

Replying to anonymous:

Adding myself to the CC list - we need remote SVN access - I'm going to try the one that's been advertised on this ticket, but I'm worried about the alpha state of it. Luckily, all of our repositories have anonymous access, so we don't need svn auth for trac's interface. I wish you folks would up the priority on this one - I'd love to see it integrated in Milestone 0.11. Thanks for the great tool anyway!

One more note: the primary reasons why we need remote access are not the usual IT department political reasons. Our team works on multiple projects that are scattered over a number of open source repositories - everything from eclipse plug-ins (and if you know anything about eclipse, then you know that their motto is, "IBM's way or the highway") to sourceforge projects to our own internal forge here at Novell. Trac is great, but we really need remote svn repositories.

comment:95 by anonymous, 17 years ago

Cc: trac@… added

will you implement this feature request?

in reply to:  95 comment:96 by martin.marcher@…, 17 years ago

Replying to anonymous:

will you implement this feature request?

iirc it has been the decision that trac will wait for the python bindings to provide this functionality and then implement it.

Afaik the problem is that pythons svn bindings only provide the functionality trac needs for file:/// URIs and not other protocols…

comment:97 by anonymous, 17 years ago

Cc: vyt@… removed

comment:98 by anonymous, 16 years ago

Cc: mdecoffe@… added

comment:99 by Christian Boos, 16 years ago

One additional note for the svnsync solution (see comment:64):

It might be useful to also run a svnsync copy-revprops command, to catch the changes to revision properties, see the svn book.

The output of that command should be parsed in order to get the list of modified changesets and then you should call trac-admin <env> resync $rev on those (if using Trac 0.10.4 or above), unless you already have a post-revprop-change hook which does this and svnsync copy-revprops calls that hook (I haven't verified that it calls it, but I assume it does).

comment:100 by madduck, 16 years ago

Cc: trac.edgewall.org@… removed

The spam filter requires me to enter something here or else I can't just remove myself from Cc. Weird.

comment:101 by radix@…, 16 years ago

You're lucky. I'm the reporter so I can't stop getting these god damned emails.

in reply to:  101 ; comment:102 by Christian Boos, 16 years ago

Reporter: changed from radix@… to radix at twistedmatrix.com

Replying to radix@twistedmatrix.com:

You're lucky. I'm the reporter so I can't stop getting these god damned emails.

Just ask ;-)

Btw, I started to write a more detailed step-by-step guide about how to setup a svnsync solution, I'll follow-up here when it's done.

comment:103 by Christopher Lenz, 16 years ago

(very sorry everyone, need to test config change to limit the amount of mails being sent out)

comment:104 by anonymous, 16 years ago

Cc: jesteves@… added

Another me-too. I need svn+ssh remote access.

in reply to:  description ; comment:105 by yuangang28@…, 16 years ago

Cc: yuangang28@… added

Replying to radix at twistedmatrix.com:

It stinks pretty bad that I have to install trac on my Subversion server AND give it write access to it.

in reply to:  105 comment:106 by Emmanuel Blot, 16 years ago

Replying to radix at twistedmatrix.com: It stinks pretty bad that I have to install trac on my Subversion server AND give it write access to it.

Use trac with a remote Subversion repository;I want to have the character too

Please do not alter the ticket summary!

comment:107 by Joymarquis, 16 years ago

Cc: joymarquis@… added

I also have such requirement because we share source from a read-only SVN server that is owned by another department.

in reply to:  107 comment:108 by Emmanuel Blot, 16 years ago

Replying to Joymarquis:

I also have such requirement because we share source from a read-only SVN server that is owned by another department.

If you have only a read-only access to the SVN repository you want to connect to Trac, an easy workaround is to create a local mirror of that remote repository and to keep your local repository in sync with a cron script.

comment:109 by anonymous, 16 years ago

Cc: a_baranenko@… added

comment:110 by anonymous, 16 years ago

Version: 0.9.20.11b1

wasnt this scheduled for 0.11 ? its like the most needed feature in trac - thousands of sourceforge developers would turn to trac overnight if this was done… keeping in mind these are all OPEN SOURCE developers meaning quite a few would help out with trac development as well….

in reply to:  110 comment:111 by Emmanuel Blot, 16 years ago

Version: 0.11b10.9.2

Replying to anonymous:

wasnt this scheduled for 0.11 ?

Read the milestone field…

comment:112 by jan-trac@…, 16 years ago

Cc: jan-trac@… added

comment:113 by anonymous, 16 years ago

i wonder why you don't use: http://pysvn.tigris.org/ doesn't it have all necessary features?

comment:114 by anonymous, 16 years ago

I've come up with a workaround for our company. Our subversion server already has viewvc installed on it (any web based subversion viewer will work) so I used the NavAddPlugin to add a link to point to the viewvc instance and then edited mainnav in my trac.ini to put the new menu item in the right place.

comment:115 by termim@…, 16 years ago

Cc: termim@… added

comment:116 by dl9pf@…, 16 years ago

Cc: dl9pf@… added

comment:117 by anonymous, 16 years ago

for a plugin that does this with an svnsync done per request, see http://trac-hacks.org/wiki/SvnsyncPlugin

comment:118 by richard@…, 16 years ago

Cc: richard@… added

Thanks for trac! I really like this project.

comment:119 by robert@…, 16 years ago

Cc: robert@… added

comment:120 by mike@…, 16 years ago

Cc: mike@… added

+1 on the interested list.

comment:121 by post@…, 16 years ago

Maybe you could priorize this a bit more (please). Track 0.13 seems so far away. Thanks

comment:122 by hieult@…, 15 years ago

The remote SVN can adapt easily on Windows by using UNC path.

I have tried the http://www.meadowy.org/~gotoh/projects/remote-svn-plugin/wiki but seem it is buggy, I can get it running, but problem with syncing. Maybe because of the revision history is big.

comment:123 by ilkka.laukkanen@…, 15 years ago

Cc: ilkka.laukkanen@… added

another potential user here.

comment:124 by manuzhai@…, 15 years ago

Cc: manuzhai@… removed

comment:125 by trac.edgewall.com@…, 15 years ago

Cc: trac.edgewall.com@… added

SPAM filter wants something here

comment:126 by trac.edgewall.com@…, 15 years ago

Cc: trac.edgewall.com@… removed

SPAM filter wants something here

comment:127 by trac@…, 15 years ago

Cc: trac@… removed

SPAM filter wants something here

comment:128 by dak@…, 15 years ago

Cc: dak@… added

comment:129 by andyh, 15 years ago

Priority: normalhigh

Is is really time to fix this now!

+1 for needed.

comment:130 by jesteves@…, 15 years ago

Cc: jesteves@… removed

Not longer interested.

comment:131 by joymarquis@…, 15 years ago

Cc: joymarquis@… removed

Remove self from the cc list. Thanks for the work.

comment:132 by lists@…, 15 years ago

Adding a comment to try to satisfy the spam filter so I can unsubscribe

comment:133 by lists@…, 15 years ago

Crap! it didn't work. How do I get off this list?

comment:134 by trac-trac@…, 15 years ago

Cc: trac-trac@… removed

Not longer interested.

comment:135 by dak@…, 15 years ago

Cc: dak@… removed

Too much spam from this list, attempting unsubscribe.

in reply to:  88 comment:136 by anonymous, 15 years ago

Replying to anonymous:

jasonm23@… - remove please.

in reply to:  75 comment:137 by anonymous, 15 years ago

Replying to lists@…:

lists@… - remove please

comment:138 by anonymous, 15 years ago

Resolution: wontfix
Status: newclosed

comment:139 by anonymous, 15 years ago

Resolution: wontfix
Status: closedreopened

Too many people are asking for this for an anonymous "wont fix" to be appropriate. You may not fix it, but it is an Open Source project, therefore someone else may fix it. At least leave an explanation of your decision to close it.

I am reopening it.

comment:140 by anonymous, 15 years ago

+1, really want this feature badly

comment:141 by ilkka.laukkanen@…, 15 years ago

Cc: ilkka.laukkanen@… removed

removing cc

comment:142 by lists@…, 15 years ago

Cc: lists@… removed

comment:143 by andy@…, 15 years ago

Cc: andy@… added

This would be useful for me to make the fine grained permission sharing between svnserve, the Apache SVN authz module and Trac automatic, and to mean that I can think about restricting direct file access to the SVN repos for security reasons. +1, for what it matters ;)

comment:144 by bbdakraxor@…, 15 years ago

Cc: bbdakraxor@… added

I can't believe this ticket has been around for 5 years. This feature would be useful for several reasons, most of them are mentioned above in the comments. Python is one of the few languages I'm not really familiar with, otherwise I'd go ahead and do it myself. I don't want to quit using Trac but right now this is causing me serious problems. If I were competent, I'd raise priority and severity. Please consider.

+1 user requesting this feature!

comment:145 by matthew.block@…, 15 years ago

Cc: matthew.block@… removed

Remove me from the CC

comment:146 by bbdakraxor@…, 15 years ago

Forgot to add: can't thank the developers enough for this GREAT project!

comment:147 by Christian Boos, 15 years ago

Description: modified (diff)

There are many possible solutions to this ticket.

  • implement a new VersioningSystemBackend
    • using Subversion SWIG Python bindings, the svn_ra layer API. This has been tried by Shun-ichi Goto, it worked somehow, with some weak points due to bugs in the bindings, IIRC. Unfortunately, that plugin doesn't seem to be available anymore.
    • using Subversion ctypes bindings (with svn 1.5).
    • using the PySVN bindings (not a good idea according to comment:72) Any of the above is possible, and if a good working implementation emerges, then I'm sure it can find its way into Trac proper.
  • workaround the limitation by replicating the remote svn repository
    • have a post-commit-hook in the main repository which triggers a svnsync to the Trac-dedicated repository (comment:64)
    • trigger a svnsync from Trac (TracHacks:SvnsyncPlugin, comment:117)
    • mirror the svn repository using git or Mercurial and have Trac use the mirror

So yes, using a remote Subversion repository is not yet as easy as putting an http://… URL in the repository_dir, but there are solutions.

I think there are enough +1 voices here so that there's no need to add more… Please consider adding to this ticket only if you want to share with the numerous people on the CC: list a new information about this issue (in particular, an update from Shun-Ichi would be more than welcomed).

in reply to:  147 comment:148 by Felix Schwarz <felix.schwarz@…>, 15 years ago

Replying to cboos:

  • using Subversion SWIG Python bindings, the svn_ra layer API. This has been tried by Shun-ichi Goto, it worked somehow, with some weak points due to bugs in the bindings, IIRC. Unfortunately, that plugin doesn't seem to be available anymore.

I think it still is - new repository seems to be http://www.meadowy.org/~gotoh/hg/remote-svn-plugin/

comment:149 by linux-madagascar@…, 15 years ago

Cc: linux-madagascar@… added

Who'se company/employer would be ready to pay some freelance in order to work on this? I estimate the work time 0.5~0.75 month…

comment:150 by Thijs Triemstra <info@…>, 15 years ago

Cc: info@… added

big +1, especially when the idea has been around for 5 years. Subversion marked the ctypes python bindings integration as one of their Google Summer of Code projects, so people that are interested in getting paid to fix that should check it out.

comment:151 by thomas.subera@…, 15 years ago

Cc: thomas.subera@… removed

comment:152 by Karaszi István <trac@…>, 15 years ago

Cc: trac@… removed

comment:153 by anonymous, 14 years ago

ugh. really? no activity for 7 months? ok. fine. had enough, off to redmine.

comment:154 by Christian Boos, 14 years ago

Description: modified (diff)
Milestone: 0.132.0

comment:155 by Christian Boos, 14 years ago

… and speaking about Redmine, I just had a look and they're just using the svn command line, which is, how to say it nicely, perhaps the smartest way to avoid the nightmarish aspect of the bindings, the associated memory leaks and the various limitations including the lack of remote access discussed here (not to mention the numerous installation horror stories…).

So an other alternative would be to just do the same and have a backend based on the svn command line, somewhat like the GitPlugin does.

comment:156 by anonymous, 14 years ago

yes that would be great! and you can avoid many things. We had a major network reorganization and since then we are still trying to get the subversion support up an running again (windows domain issues). Could this be done in 0.11.x or 0.12?

comment:157 by sorin.sbarnea@…, 14 years ago

+1 for this (I can't use the vote feature because I cannot create an account)

comment:158 by anonymous, 14 years ago

A svn+ssh would be great, because I can't install anything on on the svn server…

comment:159 by rflegel@…, 14 years ago

Cc: rflegel@… removed

comment:160 by Ryan Ollos <ryano@…>, 14 years ago

Cc: ryano@… added

in reply to:  158 comment:161 by anonymous, 14 years ago

Replying to anonymous:

A svn+ssh would be great, because I can't install anything on on the svn server…

Could you explain more? Currently, I have a SVN server runs in difference Server, I only access via svn protocol(svn://<IP>/). My Trac runs in on others one, I am trying to connect them together, but fail.

comment:162 by jae+trac@…, 14 years ago

Cc: jae+trac@… added

Hmm, weird… there's a "Milestone changed from 0.11 to 0.12" and a "Milestone changed from 0.13 to 2.0", but I don't see a 0.12→0.13?

Oh, and doesn't "2.0" sound a lot like "probably never"?

in reply to:  162 comment:163 by Remy Blank, 14 years ago

Replying to jae+trac@…:

Hmm, weird… there's a "Milestone changed from 0.11 to 0.12" and a "Milestone changed from 0.13 to 2.0", but I don't see a 0.12→0.13?

That's #5658.

Oh, and doesn't "2.0" sound a lot like "probably never"?

Quite close, until either:

  • a core developer has the need for the functionality, at which point he may choose to implement it, or
  • someone champions the functionality and provides a complete patch that integrates cleanly with trunk.

So far, none of these has been the case.

comment:164 by Christian Boos, 14 years ago

Milestone: 2.0unscheduled

Milestone 2.0 deleted

comment:165 by Christian Boos, 14 years ago

Milestone: triagingunscheduled

(according to the nice summary given by Remy in comment:163)

comment:166 by crazedfred@…, 14 years ago

Cc: crazedfred@… added

comment:167 by chris.tandiono@…, 14 years ago

Cc: chris.tandiono@… added

comment:168 by anonymous, 13 years ago

To host the web-frontend on the same server as the often secret and critial repositories? I can not imagine many peoples or organisations that would knowingly accept such risk. And this ticket is 6 years old?! Wow, it's a shame, Trac looks really nice but this is a complete show stopper for me.

comment:169 by anonymous, 13 years ago

Maybe this could help: http://code.google.com/p/gvn/

""" gvn is a Subversion client written in Python. For nearly all operations, it simply execs the standard svn program. For others, it uses the Python binding to implement its own logic. Current features are:

  • "Review Then Commit" model, by copying locally modified files to a "change branch", with commands to snapshot, review, and submit the change, including deletion of the branch.
  • Short-hand URLs: instead of http://svn/repo
  • tkdiff integration

"""

comment:170 by anonymous, 13 years ago

From the looks of things here, Trac is falling prey to the typical open source folly:

"I'm writing this software, and I'm not charging you for it, so if you don't like it, leave"

It's an easy thing to do to forget that even though you aren't writing a piece of software for someone else, thousands of people will use it, and if you are nice enough to those thousands of people and make them happy enough, some of them might even donate some money to you… Not to mention that if you can get major corporations using your open source project you'll get contributors as the coders from those major corporations will stop in to bug fix mission critical bugs.

Me personally, this isn't a show stopper, but it is a pain, because it means I'll have to reorganize my EXISTING systems to allow trac to be part of the flow, and isn't that against the published philosophy of trac? "Trac should stay out of the way"

comment:171 by anonymous, 13 years ago

I've been subscribed to this ticket since 2007. It's unbelievable that this has not yet been implemented.

comment:172 by Remy Blank, 13 years ago

Before anybody adds new comments, please:

  • Read comment:147.
  • Read about Shun-ichi Goto's plugin (link in the description).
  • Read about svnsync.
  • Consider contributing constructively, by submitting code, instead of moaning about missing functionality.
  • Be aware that none of us does this for the money.

Thank you.

comment:173 by olemis+trac@…, 12 years ago

Cc: olemis+trac@… added

in reply to:  102 ; comment:174 by Mark Potter <mpotter@…>, 11 years ago

Cc: mpotter@… added

Replying to cboos:

Btw, I started to write a more detailed step-by-step guide about how to setup a svnsync solution, I'll follow-up here when it's done.

Did not find this write up. Did it ever happen?

in reply to:  174 comment:175 by Christian Boos, 11 years ago

Replying to Mark Potter <mpotter@…>:

Replying to cboos:

Btw, I started to write a more detailed step-by-step guide about how to setup a svnsync solution, I'll follow-up here when it's done.

Did not find this write up. Did it ever happen?

Not by me, and I couldn't find anything in my personal notes. However someone else contributed this recipe here TracMigrate#SubversionReplication which can be a starting point. In addition you'd have to setup a cronjob or something to periodically pull in new commits (svn sync file:///location/of/your/mirror).

comment:176 by Thijs Triemstra, 11 years ago

Cc: info@… removed

comment:177 by anonymous, 11 years ago

hmmm - so does anybody from developer's team can answer on one simple question - WHEN this bug will be closed?

comment:178 by dewey@…, 11 years ago

Cc: dewey@… removed

comment:179 by anonymous, 11 years ago

Recently Subversion 1.8 has changed repository format. So Trac just claims that it expects FS format from 1 to 4, but not 6. Will the support of remote repository somehow resolve or mitigate such dependence? To postpone an update of Subversion due to lack of support from issue tracker is quite frustrating.

in reply to:  179 ; comment:180 by anonymous, 11 years ago

Replying to anonymous:

[…] Trac just claims that it expects FS format from 1 to 4, but not 6.

Most likely the Python bindings for Subversion used by Trac are < 1.8.

in reply to:  180 comment:181 by anonymous, 11 years ago

Replying to anonymous:

Replying to anonymous:

[…] Trac just claims that it expects FS format from 1 to 4, but not 6.

Most likely the Python bindings for Subversion used by Trac are < 1.8.

Obviously. Now I'm trying to marry python bingings from svn 1.8 to Trac 1.0.1. With no success yet - missing some dlls not present in svn packages nor in my WinXP. It's not straightforward for outsider anyway.

comment:182 by Ryan J Ollos, 11 years ago

I don't see a ticket on t.e.o for SVN 1.8 support, but if you have some useful information to provide about the issues that have been encountered, we'd certainly appreciate you creating a ticket.

comment:183 by Ryan J Ollos, 11 years ago

Cc: ryano@… removed

comment:184 by cd@…, 10 years ago

Cc: cd@… added

comment:185 by Christian Boos, 9 years ago

Milestone: unscheduled
Resolution: wontfix
Status: reopenedclosed

(at the occasion of the recent spamming of this ticket…)

In all likelihood, we're not going to invest time on supporting this feature, given that:

comment:186 by Ryan J Ollos, 9 years ago

I haven't looked into the issue, but bh:#478 suggests using SVN 1.8's publisher-subscriber system.

Last edited 8 years ago by Ryan J Ollos (previous) (diff)

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christian Boos.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Christian Boos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.