Edgewall Software
Modify

Opened 10 years ago

Last modified 6 weeks ago

#493 reopened enhancement

Use trac with a remote Subversion repository

Reported by: radix at twistedmatrix.com Owned by: cboos
Priority: high Milestone: unscheduled
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@…
Release Notes:
API Changes:

Description (last modified by cboos)

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 (184)

comment:1 Changed 10 years ago by mrowe@…

  • Severity changed from normal to enhancement

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 Changed 10 years ago by daniel

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 Changed 10 years ago by anonymous

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 Changed 10 years ago by cmlenz

  • Summary changed from Use trac with a REMOTE Subversion repository to Use trac with a remote Subversion repository

comment:5 Changed 9 years ago by Marc Sutton

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 Changed 9 years ago by cmlenz

  • 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 Changed 9 years ago by Juanma Barranquero

[...] 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 Changed 9 years ago by eric@…

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

comment:9 Changed 9 years ago by anonymous

Related to fine grained permissions question asked in this topic:

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

comment:10 Changed 9 years ago by jwt

  • Component changed from general to trac-admin
  • Keywords repository svk added
  • Owner changed from jonas to daniel
  • Version changed from 0.7 to 0.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 Changed 9 years ago by anonymous

  • Cc vyt@… added

comment:12 Changed 9 years ago by marshall@…

  • Cc marshall@… added

comment:13 Changed 9 years ago by anonymous

  • Cc slith76@… added

comment:14 Changed 9 years ago by cmlenz

  • Component changed from trac-admin to version control
  • Owner changed from daniel to cmlenz

comment:15 Changed 9 years ago by anonymous

  • Cc jwin1@… added

comment:16 Changed 9 years ago by anonymous

  • Cc changed from vyt@vzljot.ru, marshall@exclupen.com, slith76@gmail.com,jwin1@web.de to vyt@vzljot.ru, marshall@exclupen.com, slith76@gmail.com, jwin1@web.de

comment:17 Changed 9 years ago by Tobi Oetiker <oetiker@…>

  • Cc oetiker@… added
  • Version changed from 0.8.3 to 0.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 Changed 9 years ago by jwin1@…

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 Changed 9 years ago by mgood

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 Changed 9 years ago by anonymous

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 Changed 9 years ago by jwin

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 Changed 9 years ago by jwin

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

comment:23 Changed 9 years ago by jw

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 Changed 9 years ago by anonymous

  • Version changed from 0.9b2 to 0.9.2

comment:25 Changed 9 years ago by Mitch

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

comment:26 Changed 9 years ago by imp <trac@…>

  • Cc trac@… added

comment:27 Changed 9 years ago by anonymous

  • Cc anderson@… added

comment:28 Changed 9 years ago by anonymous

  • Cc azrael@… added

comment:29 Changed 9 years ago by anonymous

  • Cc cbassham@… added

comment:30 Changed 9 years ago by anonymous

  • Milestone set to 0.9.5

comment:31 Changed 9 years ago by cmlenz

  • Milestone 0.9.5 deleted

WTF?

comment:32 Changed 9 years ago by anonymous

  • 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 Changed 9 years ago by anonymous

  • Cc trac-trac@… added

comment:34 Changed 9 years ago by eblot

#2828 has been marked as a duplicate.

comment:35 Changed 8 years ago by caio1982

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 Changed 8 years ago by anonymous

  • Cc caio1982@… added

comment:37 Changed 8 years ago by anonymous

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

comment:38 Changed 8 years ago by cboos

  • Milestone set to 0.11
  • Owner changed from cmlenz to cboos
  • Priority changed from normal to low

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 Changed 8 years ago by anonymous

  • Cc edgewall.cjy@… added

comment:40 Changed 8 years ago by anonymous

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 Changed 8 years ago by Barry Scott

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 Changed 8 years ago by anonymous

  • Cc anarcat@… added

comment:43 Changed 8 years ago by anonymous

  • Cc stevej@… added

comment:44 Changed 8 years ago by caio1982

  • Priority changed from low to normal

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 Changed 8 years ago by anonymous

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 Changed 8 years ago by anonymous

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 Changed 8 years ago by Manuzhai

  • Cc manuzhai@… added

comment:48 Changed 8 years ago by anonymous

  • Cc chris.a.williams@… added

comment:49 Changed 8 years ago by anonymous

  • Cc tim_gould@… added

comment:50 Changed 8 years ago by anonymous

  • Cc jp@… added

comment:51 Changed 8 years ago by anonymous

  • Cc scott@… added

comment:52 Changed 8 years ago by anonymous

  • Cc tdussa@… added

comment:53 Changed 8 years ago by anonymous

  • Cc heikki.lampen@… added

comment:54 Changed 8 years ago by anonymous

  • Cc climaxius@… added

comment:55 Changed 8 years ago by anonymous

  • Priority changed from normal to highest

comment:56 Changed 8 years ago by mgood

  • Priority changed from highest to normal

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

comment:57 Changed 8 years ago by anonymous

  • Cc felix.schwarz@… added

comment:58 Changed 8 years ago by anonymous

  • Cc trac.edgewall.org@… added

comment:59 Changed 8 years ago by anonymous

  • Cc trac.edgewall.org@… added

comment:60 Changed 8 years ago by trac@…

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 Changed 8 years ago by cboos

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 Changed 8 years ago by anonymous

  • Cc rnc000@… added

comment:63 Changed 8 years ago by lists01@…

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 Changed 8 years ago by cboos

  • Severity changed from normal to major

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 Changed 8 years ago by anonymous

  • Cc cbassham@… removed

comment:66 Changed 8 years ago by anonymous

  • Cc anderson@… removed

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

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 Changed 8 years ago by anonymous

  • Cc martin.marcher@… added

comment:69 Changed 8 years ago by anonymous

  • Cc chris@… added

comment:70 Changed 8 years ago by chris@…

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 Changed 8 years ago by sik0fewl

  • 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 Changed 8 years ago by Shun-ichi Goto <shunichi.goto@…>

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 follow-up: Changed 8 years ago by cboos

  • Milestone changed from 0.11 to 0.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 Changed 8 years ago by anonymous

  • Cc soloturn@… added

comment:75 follow-up: Changed 8 years ago by lists@…

  • Cc lists@… added

comment:76 Changed 8 years ago by anonymous

  • Cc rnc000@… removed

removed my email from CC

comment:77 in reply to: ↑ 73 Changed 8 years ago by Dan <trac@…>

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 Changed 7 years ago by anonymous

  • Cc imanuel.scholz@… added

comment:79 Changed 7 years ago by anonymous

  • Cc nslater@… added

comment:80 Changed 7 years ago by anonymous

  • Cc tim_gould@… removed

comment:81 Changed 7 years ago by anonymous

  • Cc jyrki.muukkonen@… added

comment:82 Changed 7 years ago by anonymous

  • Cc dewey@… added

comment:83 Changed 7 years ago by anonymous

  • Cc sergei@… added

comment:84 Changed 7 years ago by anonymous

  • Cc thomas.subera@… added

comment:85 Changed 7 years ago by anonymous

  • Cc sloukam@… added

comment:86 Changed 7 years ago by anonymous

  • Cc dstaple@… added

comment:87 Changed 7 years ago by anonymous

  • Cc buckett@… added

comment:88 follow-up: Changed 7 years ago by anonymous

  • Cc jasonm23@… added

comment:89 Changed 7 years ago by anonymous

  • Cc matthew.block@… added

comment:90 Changed 7 years ago by ryanmccue@…

  • 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 Changed 7 years ago by anonymous

  • Cc stevej@… removed

comment:92 Changed 7 years ago by anonymous

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

comment:93 follow-up: Changed 7 years ago by anonymous

  • 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!

comment:94 in reply to: ↑ 93 Changed 7 years ago by anonymous

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 follow-up: Changed 7 years ago by anonymous

  • Cc trac@… added

will you implement this feature request?

comment:96 in reply to: ↑ 95 Changed 7 years ago by martin.marcher@…

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 Changed 7 years ago by anonymous

  • Cc vyt@… removed

comment:98 Changed 7 years ago by anonymous

  • Cc mdecoffe@… added

comment:99 Changed 7 years ago by cboos

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 Changed 7 years ago by madduck

  • 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 follow-up: Changed 7 years ago by radix@…

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

comment:102 in reply to: ↑ 101 ; follow-up: Changed 7 years ago by cboos

  • 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 Changed 7 years ago by cmlenz

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

comment:104 Changed 7 years ago by anonymous

  • Cc jesteves@… added

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

comment:105 in reply to: ↑ description ; follow-up: Changed 7 years ago by yuangang28@…

  • 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.

comment:106 in reply to: ↑ 105 Changed 7 years ago by eblot

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 follow-up: Changed 7 years ago by Joymarquis

  • Cc joymarquis@… added

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

comment:108 in reply to: ↑ 107 Changed 7 years ago by eblot

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 Changed 7 years ago by anonymous

  • Cc a_baranenko@… added

comment:110 follow-up: Changed 6 years ago by anonymous

  • Version changed from 0.9.2 to 0.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….

comment:111 in reply to: ↑ 110 Changed 6 years ago by eblot

  • Version changed from 0.11b1 to 0.9.2

Replying to anonymous:

wasnt this scheduled for 0.11 ?

Read the milestone field…

comment:112 Changed 6 years ago by jan-trac@…

  • Cc jan-trac@… added

comment:113 Changed 6 years ago by anonymous

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

comment:114 Changed 6 years ago by anonymous

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 Changed 6 years ago by termim@…

  • Cc termim@… added

comment:116 Changed 6 years ago by dl9pf@…

  • Cc dl9pf@… added

comment:117 Changed 6 years ago by anonymous

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

comment:118 Changed 6 years ago by richard@…

  • Cc richard@… added

Thanks for trac! I really like this project.

comment:119 Changed 6 years ago by robert@…

  • Cc robert@… added

comment:120 Changed 6 years ago by mike@…

  • Cc mike@… added

+1 on the interested list.

comment:121 Changed 6 years ago by post@…

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

comment:122 Changed 6 years ago by hieult@…

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 Changed 6 years ago by ilkka.laukkanen@…

  • Cc ilkka.laukkanen@… added

another potential user here.

comment:124 Changed 6 years ago by manuzhai@…

  • Cc manuzhai@… removed

comment:125 Changed 6 years ago by trac.edgewall.com@…

  • Cc trac.edgewall.com@… added

SPAM filter wants something here

comment:126 Changed 6 years ago by trac.edgewall.com@…

  • Cc trac.edgewall.com@… removed

SPAM filter wants something here

comment:127 Changed 6 years ago by trac@…

  • Cc trac@… removed

SPAM filter wants something here

comment:128 Changed 6 years ago by dak@…

  • Cc dak@… added

comment:129 Changed 6 years ago by andyh

  • Priority changed from normal to high

Is is really time to fix this now!

+1 for needed.

comment:130 Changed 6 years ago by jesteves@…

  • Cc jesteves@… removed

Not longer interested.

comment:131 Changed 6 years ago by joymarquis@…

  • Cc joymarquis@… removed

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

comment:132 Changed 6 years ago by lists@…

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

comment:133 Changed 6 years ago by lists@…

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

comment:134 Changed 6 years ago by trac-trac@…

  • Cc trac-trac@… removed

Not longer interested.

comment:135 Changed 6 years ago by dak@…

  • Cc dak@… removed

Too much spam from this list, attempting unsubscribe.

comment:136 in reply to: ↑ 88 Changed 6 years ago by anonymous

Replying to anonymous:

jasonm23@… - remove please.

comment:137 in reply to: ↑ 75 Changed 6 years ago by anonymous

Replying to lists@…:

lists@… - remove please

comment:138 Changed 6 years ago by anonymous

  • Resolution set to wontfix
  • Status changed from new to closed

comment:139 Changed 6 years ago by anonymous

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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 Changed 6 years ago by anonymous

+1, really want this feature badly

comment:141 Changed 6 years ago by ilkka.laukkanen@…

  • Cc ilkka.laukkanen@… removed

removing cc

comment:142 Changed 6 years ago by lists@…

  • Cc lists@… removed

comment:143 Changed 6 years ago by andy@…

  • 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 Changed 6 years ago by bbdakraxor@…

  • 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 Changed 6 years ago by matthew.block@…

  • Cc matthew.block@… removed

Remove me from the CC

comment:146 Changed 6 years ago by bbdakraxor@…

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

comment:147 follow-up: Changed 6 years ago by cboos

  • 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).

comment:148 in reply to: ↑ 147 Changed 6 years ago by Felix Schwarz <felix.schwarz@…>

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 Changed 5 years ago by linux-madagascar@…

  • 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 Changed 5 years ago by Thijs Triemstra <info@…>

  • 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 Changed 5 years ago by thomas.subera@…

  • Cc thomas.subera@… removed

comment:152 Changed 5 years ago by Karaszi István <trac@…>

  • Cc trac@… removed

comment:153 Changed 5 years ago by anonymous

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

comment:154 Changed 5 years ago by cboos

  • Description modified (diff)
  • Milestone changed from 0.13 to 2.0

comment:155 Changed 5 years ago by cboos

… 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 Changed 5 years ago by anonymous

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 Changed 5 years ago by sorin.sbarnea@…

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

comment:158 follow-up: Changed 5 years ago by anonymous

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

comment:159 Changed 5 years ago by rflegel@…

  • Cc rflegel@… removed

comment:160 Changed 5 years ago by Ryan Ollos <ryano@…>

  • Cc ryano@… added

comment:161 in reply to: ↑ 158 Changed 5 years ago by anonymous

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 follow-up: Changed 5 years ago by jae+trac@…

  • 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"?

comment:163 in reply to: ↑ 162 Changed 5 years ago by rblank

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 Changed 4 years ago by cboos

  • Milestone changed from 2.0 to unscheduled

Milestone 2.0 deleted

comment:165 Changed 4 years ago by cboos

  • Milestone changed from triaging to unscheduled

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

comment:166 Changed 4 years ago by crazedfred@…

  • Cc crazedfred@… added

comment:167 Changed 4 years ago by chris.tandiono@…

  • Cc chris.tandiono@… added

comment:168 Changed 4 years ago by anonymous

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 Changed 4 years ago by anonymous

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 Changed 3 years ago by anonymous

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 Changed 3 years ago by anonymous

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

comment:172 Changed 3 years ago by rblank

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 Changed 2 years ago by olemis+trac@…

  • Cc olemis+trac@… added

comment:174 in reply to: ↑ 102 ; follow-up: Changed 16 months ago by Mark Potter <mpotter@…>

  • 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?

comment:175 in reply to: ↑ 174 Changed 16 months ago by cboos

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 Changed 16 months ago by thijstriemstra

  • Cc info@… removed

comment:177 Changed 15 months ago by anonymous

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

comment:178 Changed 15 months ago by dewey@…

  • Cc dewey@… removed

comment:179 follow-up: Changed 13 months ago by anonymous

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.

comment:180 in reply to: ↑ 179 ; follow-up: Changed 13 months ago by 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.

comment:181 in reply to: ↑ 180 Changed 13 months ago by anonymous

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 Changed 13 months ago by rjollos

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 Changed 13 months ago by rjollos

  • Cc ryano@… removed

comment:184 Changed 6 weeks ago by cd@…

  • Cc cd@… added

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as reopened The owner will remain cboos.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from cboos to anonymous. Next status will be 'assigned'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.