[OT] Plugins: svn-externals or not?

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 W. [email protected]:

  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.

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

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
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/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 Z., Ph.D.
[email protected]
Subversion and Orca training and consulting
http://www.orcaware.com/svn/

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.
[email protected]
Subversion and Orca training and consulting
http://www.orcaware.com/svn/

2005/12/14, Blair Z. [email protected]:

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 :slight_smile: 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 !