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
Hi ! 2005/12/13, Ryan Wood <ryan.wood@gmail.com>:> 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 That way, you can at least decide when you are going to upgrade your plugins.> 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.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 \ vendor/plugins/plugin-name svn commit -m "Merged changes 1234:4567 from 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 \ 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 ! -- François Beausoleil http://blog.teksol.info/ _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Francois Beausoleil wrote:> Hi ! > > 2005/12/13, Ryan Wood <ryan.wood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>: >>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. > > > 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 \ > vendor/plugins/plugin-name > svn commit -m "Merged changes 1234:4567 from > 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 \ 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.> 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 \ > vendor/plugins/plugin-name > svn propset last-merged-revision 4567 vendor/plugins/plugin-name > svn commit -m "Merged changes 1234:4567 fromYou 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.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 Zajac, Ph.D. <blair-szbw9MROnEZWk0Htik3J/w@public.gmane.org> Subversion and Orca training and consulting http://www.orcaware.com/svn/
2005/12/14, Blair Zajac <blair@orcaware.com>:> 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 ! -- François Beausoleil http://blog.teksol.info/ _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Francois Beausoleil wrote:> 2005/12/14, Blair Zajac <blair-szbw9MROnEZWk0Htik3J/w@public.gmane.org>: > >>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.That''s too funny. I wrote svn_load_dirs.pl! Regards, Blair -- Blair Zajac, Ph.D. <blair-szbw9MROnEZWk0Htik3J/w@public.gmane.org> Subversion and Orca training and consulting http://www.orcaware.com/svn/