Syncing library/project subversion respositories

Question

I'm developing a library alongside several projects that use it, and I've found myself frequently modifying the library at the same time as a project (e.g., adding a function to the library and immediately using it in the project). As a result, the project would no longer compile with previous versions of the library.

So if I need to rollback a change or test a previous version of the project, I'd like to know what version of the library was used at check-in. I suppose I could do this manually (by just writing the version number in the log file), but it would be great if this could happen automatically.

Answer 1

One option is to use a single subversion repository and check-in changes that effect both library and project at the same time. That way you know that whatever revision of the project you are on requires the same revision of the library.

Answer 2

I think if I were going to do this, I would use tags. It would be pretty easy to write a script that would tag both repositories with the same ID each time you upgraded the library and used it in the project. Then, if you need to roll back to a previous version, you just see what its most recent tag was, and roll the library back to that version.

UPDATE: Sorry, I've been in Mercurial land for a while, and forgot that subversion doesn't directly support tagging. Assuming you use the usual subversion directory structure

/
  /trunk
  /tags
  /branches

you just need to run

svn copy trunk/ tags/TagName

on both repos, with the same tag name. Subversion is pretty good about smart copies, so you don't need to worry about disk space.

Answer 3

An option that might work for you is to use an svn:external reference to the library. When tagging the project, you can do one of two things:

• Update the svn:external to refer to a specific revision of the library; OR
• Update the svn:external to refer to a new tag that you make on the library.

Since the svn:external metadata will be part of the main project's commit history, you can always get the tag on the main project and it will refer to the correct version of the library. We do it and it works very well. It also comes in handy when you want to freeze the version of the library code that you depend on in preparation for a release.

Answer 4

You might find piston provides a solution

It's primarily used for importing ruby on rails plugins, but I don't see why it shouldn't work for any subversion repositories.

Basically what it does is this:

• svn export latest revision of the remote path
• commit these files into your local svn as if they were local files
• attach metadata in the form of svn properties about the remote path and revision

This means you can keep a reference to a particular version of a remote repo without having to have it constantly updated like with an svn external.

if you want to update your local copy of the library to the latest remote version, you just do piston update

You should also be able to look at the history of updates, by simply looking at the metadata - svn properties are versioned just like files and everything else