Forum: Ruby on Rails [OT] Plugins: svn-externals or not?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
E37ca8b3eee534fa6781f7ba13743afb?d=identicon&s=25 Ryan Wood (Guest)
on 2005-12-14 00:20
(Received via mailing list)
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
3dd4b52a0946bd698b1d1635a46ea3a3?d=identicon&s=25 Francois Beausoleil (Guest)
on 2005-12-14 00:57
(Received via mailing list)
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 !
27c57aaa4bda5ac8b0593659573b522f?d=identicon&s=25 Blair Zajac (Guest)
on 2005-12-14 23:44
(Received via mailing list)
Francois Beausoleil 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 \
>   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 from

You can use the Python svnmerge.py script from

http://svn.collab.net/repos/svn/trunk/contrib/clie...
http://svn.collab.net/repos/svn/trunk/contrib/clie...

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@orcaware.com>
Subversion and Orca training and consulting
http://www.orcaware.com/svn/
3dd4b52a0946bd698b1d1635a46ea3a3?d=identicon&s=25 Francois Beausoleil (Guest)
on 2005-12-15 03:46
(Received via mailing list)
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 !
27c57aaa4bda5ac8b0593659573b522f?d=identicon&s=25 Blair Zajac (Guest)
on 2005-12-15 20:22
(Received via mailing list)
Francois Beausoleil 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 Zajac, Ph.D.
<blair@orcaware.com>
Subversion and Orca training and consulting
http://www.orcaware.com/svn/
This topic is locked and can not be replied to.