# \[OT\] Plugins: svn-externals or not? **URL:** \ **Category:** Rails\ **Created:** [December 14, 2005, 12:20am UTC](https://www.ruby-forum.com/t/ot-plugins-svn-externals-or-not/100963 "2005-12-14T00:20:42Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![jimmyether](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e9a140/32.png) [@jimmyether](https://www.ruby-forum.com/u/jimmyether)\ **Post date:** [December 14, 2005, 12:20am UTC](https://www.ruby-forum.com/t/ot-plugins-svn-externals-or-not/100963/1 "2005-12-14T00:20:42Z")
I’m currently using svn:externals to pull plugins into my application. I’ve run into an issue and wanted to know how others are handling it. 1. I’m concerned that in the future, an update to the external repository would break my app (since changes are pulled on each update). Is it better to get the files from the repository and put it in the application’s plugins folder directly, or to use svn:externals? 2. Also, if (for what ever reason) you need to alter a file from an svn:externals repository but do not have commit rights, you can never checkin or share those changes with other’s developing the app. On the other hand, if you add it directly into your applications repository, you cannot (at least I haven’t figured it out yet) get bug fixes and updates to the plugin repository. I’d love to hear how people are handing this with their plugins… –Ryan ---
**Author:** ![jimmyether](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e9a140/32.png) [@jimmyether](https://www.ruby-forum.com/u/jimmyether)\ **Post date:** [December 14, 2005, 12:57am UTC](https://www.ruby-forum.com/t/ot-plugins-svn-externals-or-not/100963/2 "2005-12-14T00:57:23Z")
Hi ! 2005/12/13, Ryan W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): > 1. I’m concerned that in the future, an update to the external > repository would break my app (since changes are pulled on each > update). Is it better to get the files from the repository and put it > in the application’s plugins folder directly, or to use svn:externals? This is entirely possible. Depends on how far away from releasing you are. If you will release in the next near future, I’d advise you to lock to a specific revision of the remote tree: plugin-name -r1234 [http://plugin.com/svn/plugin-name/trunk](http://plugin.com/svn/plugin-name/trunk) That way, you can at least decide when you are going to upgrade your plugins. > 1. Also, if (for what ever reason) you need to alter a file from an > svn:externals repository but do not have commit rights, you can never > checkin or share those changes with other’s developing the app. > > On the other hand, if you add it directly into your applications > repository, you cannot (at least I haven’t figured it out yet) get bug > fixes and updates to the plugin repository. For that, you need to merge the changes from the remote repository. Something like that: svn merge -r1234:HEAD [http://plugin.com/svn/plugin-name/trunk](http://plugin.com/svn/plugin-name/trunk) vendor/plugins/plugin-name svn commit -m “Merged changes 1234:4567 from [http://plugin.com/svn/plugin-name/trunk](http://plugin.com/svn/plugin-name/trunk)” Subversion does not yet have merge tracking. Once it has that, it will be easy to merge multiple times from a remote repository. Until then, you have to remember which revision you last merged from. Subversion to the rescue again: svn merge -r1234:HEAD [http://plugin.com/svn/plugin-name/trunk](http://plugin.com/svn/plugin-name/trunk) vendor/plugins/plugin-name svn propset last-merged-revision 4567 vendor/plugins/plugin-name svn commit -m "Merged changes 1234:4567 from Myself ? I use svn:externals and track HEAD of all plugins and Rails. I’m still two four weeks away from release, though. Although, with 1.0 out the door, I’ll lock down Rails to 1.0. Bye ! ---
**Author:** ![jimmyether](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e9a140/32.png) [@jimmyether](https://www.ruby-forum.com/u/jimmyether)\ **Post date:** [December 14, 2005, 11:44pm UTC](https://www.ruby-forum.com/t/ot-plugins-svn-externals-or-not/100963/3 "2005-12-14T23:44:47Z")
Francois B. wrote: > For that, you need to merge the changes from the remote repository. > Something like that: > > svn merge -r1234:HEAD [http://plugin.com/svn/plugin-name/trunk](http://plugin.com/svn/plugin-name/trunk) > vendor/plugins/plugin-name > svn commit -m “Merged changes 1234:4567 from > [http://plugin.com/svn/plugin-name/trunk](http://plugin.com/svn/plugin-name/trunk)” You may want to use the explicit revision in the merge command instead of HEAD in case there’s a revision that is committed to the source repository while this is working. If that does happen, then the commit message is out of date. It’s a little anal, but it reduces one more than that can go wrong. Another point, that if the external repository adds a new file into their repository, the merge will fail due to a limitation of the Subversion client. There is an open ticket for it, but it’s not resolved yet. So if you were doing merge tracking like this against Ruby on Rails stable branch, which I was doing, that was getting a lot of new files being added, I was stuck. I ended up doing something like this: $ svn diff -r1234:2345 [http://plugin.com/svn/plugin-name/trunk](http://plugin.com/svn/plugin-name/trunk) vendor/plugins/plugin-name \ > patch > $ patch -p0 \< patch Finally, I then ‘svn add’ and ‘svn rm’ any files that shouldn’t be in my repository, by comparing my working copy with another working copy checked out from [http://plugin.com/svn/plugin-name/trunk](http://plugin.com/svn/plugin-name/trunk). > Subversion does not yet have merge tracking. Once it has that, it > will be easy to merge multiple times from a remote repository. Until > then, you have to remember which revision you last merged from. > Subversion to the rescue again: > svn merge -r1234:HEAD [http://plugin.com/svn/plugin-name/trunk](http://plugin.com/svn/plugin-name/trunk) > vendor/plugins/plugin-name > svn propset last-merged-revision 4567 vendor/plugins/plugin-name > svn commit -m "Merged changes 1234:4567 from You can use the Python svnmerge.py script from [http://svn.collab.net/repos/svn/trunk/contrib/client-side/svnmerge.py](http://svn.collab.net/repos/svn/trunk/contrib/client-side/svnmerge.py) [http://svn.collab.net/repos/svn/trunk/contrib/client-side/svnmerge.README](http://svn.collab.net/repos/svn/trunk/contrib/client-side/svnmerge.README) to keep track of merged revisions. This script adds a svn-merge-integrated property into the top level directory which receives the merges and this stores which revisions have been merged over. So the next time you run svnmerge.py, you only get the revisions you haven’t previously merged over. Regards, Blair – Blair Z., Ph.D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subversion and Orca training and consulting [http://www.orcaware.com/svn/](http://www.orcaware.com/svn/) ---
**Author:** ![jimmyether](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e9a140/32.png) [@jimmyether](https://www.ruby-forum.com/u/jimmyether)\ **Post date:** [December 15, 2005, 8:22pm UTC](https://www.ruby-forum.com/t/ot-plugins-svn-externals-or-not/100963/4 "2005-12-15T20:22:30Z")
Francois B. wrote: > out of an exported revision tree. It does handle moves, adds and > deletes. That’s too funny. I wrote svn\_load\_dirs.pl! Regards, Blair – Blair Z., Ph.D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subversion and Orca training and consulting [http://www.orcaware.com/svn/](http://www.orcaware.com/svn/) ---
**Author:** ![jimmyether](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e9a140/32.png) [@jimmyether](https://www.ruby-forum.com/u/jimmyether)\ **Post date:** [December 15, 2005, 3:46am UTC](https://www.ruby-forum.com/t/ot-plugins-svn-externals-or-not/100963/5 "2005-12-15T03:46:04Z")
2005/12/14, Blair Z. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): > You may want to use the explicit revision in the merge command instead of HEAD > in case there’s a revision that is committed to the source repository while this > is working. If that does happen, then the commit message is out of date. It’s > a little anal, but it reduces one more than that can go wrong. My point was illustrative 🙂 But I do get yours. Also, there is svn\_load\_dirs.pl that can be used to track, except you’ll have to work out of an exported revision tree. It does handle moves, adds and deletes. Bye !