On Jul 10, 2006, at 12:37, Chris Flerackers wrote:
> I've been looking for a way to manage dependencies between
> libraries, tools and projects in svn. For example, I have project X
> that uses library Y
>
> - project X
> - library Y
>
> Library Y is in constant development, but project X only would like
> to use stable versions of this dependency. So we make tags for Y.
>
> e.g.
>
> - tags
> - library Y
> - 1.0
> - 1.1
> - 1.2
> - 1.3
> - trunk
> - project X
> - library Y
>
> Another complication is that library Y is quite big.
>
> I have tried the following:
>
> 1) use svn:externals
> I added an svn:externals property on trunk/project X for
> tags/library Y/1.2
> But when I change the property afterwards to
> tags/library Y/1.3
> the previous library Y is completely deleted, and 1.3 is completely
> downloaded again. If you consider that library Y is e.g. 500 MB,
> this is not practical.
>
> 2) merging
> As explained in the svn book, I could consider library Y a
> "thirdpartydrop" for project X. However, then we need to constantly
> merge, which is cumbersome and wastes a lot of diskspace.
>
>
> Is there a way to manage dependencies in svn that has the following
> features:
> - easy to update to new version of dependency (e.g. like
> svn:externals)
> - only update what has changed between the 2 versions of the
> dependencies (e.g. like merging)
Just thinking out loud here...
1. You could point your external at not tags of library Y but at a
specific stable branch of library Y. I'm doing this for some of our
libraries here. For example if I declare that all 1.x versions of the
library are backwards-compatible, then I can point the external at a
branch 1.x. I can still make tags from that as reference points, but
don't need to constantly change the external definition. As soon as I
want to make a backwards-incompatible change to the library, I can
start a new 2.x branch, and if a project wants to use that, then the
project has to be slightly rewritten anyway, and at that time, the
external definition can be changed. To meet your goal, this assumes
that such backwards-incompatible changes don't occur often. In our
case, the libraries are very small, so we haven't worried about the
need to download them again.
2. Maybe you could handle externals manually. In the trunk of project
X, have a directory for library Y which is empty and contains a
readme.txt with instructions to the user to manually switch that
directory to the latest tag of the library, and to keep it up to date
as new versions of the library are tagged. svn switch only transfers
diffs over the network so that should be manageable. The difficulty
may be in getting people to keep this pointing at the latest tag. You
might need to see if you can build something into both the library
and the code that uses it that checks to see if the version matches.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jul 10 13:59:50 2006