Re: Managing dependencies

Hi Ryan,

Thanks for the comments. Please see below.

Ryan Schmidt wrote:
>
> 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.

We have an SDK that uses some tools, and the SDK is then used by other
applications. I think branching each version would still be a lot of
work in our case.

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

Seems like a good idea (the buildscript could even do the switch if
necessary), but then it would probably need to be done recursively (e.g.
application -> sdk -> tool)?

Do you happen to know if there are subversion changes on the horizon
that would simplify this way of working?

-- 
Best regards,
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org