You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Chris Flerackers <cf...@androme.be> on 2006/07/10 10:37:04 UTC
Managing dependencies
Hi,
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)
--
Best regards,
Chris
------------------------------------------------------------
Chris Flerackers Tel: (+32) 11 30 13 30
ANDROME NV Fax: (+32) 11 30 13 31
Wetenschapspark 4 mailto:cflerackers@androme.be
B-3590 Diepenbeek, Belgium http://www.androme.be
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Managing dependencies
Posted by Chris Flerackers <cf...@androme.be>.
Hi Ryan,
I saw this on the 1.4 changelog
* use switch/relocate when svn:externals updated (issue #2209)
http://subversion.tigris.org/issues/show_bug.cgi?id=2209
Subversion 1.4.0 (late June or early July 2006)
So I guess svn:externals will work as desired soon ;-)
--
Best regards,
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Managing dependencies
Posted by Chris Flerackers <cf...@androme.be>.
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
Re: Managing dependencies
Posted by Ryan Schmidt <su...@ryandesign.com>.
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