How to manage historical externals in SVN

Hi!

I have some projects which use a few externals (libraries) that are likely to change overtime. I try and keep the project clean with the trunk/branches/tags pattern, and when I make a tag (or release), I'd like to freeze the entire source in time, that is, the externals as they were at that time.

I can think of two ways to do this:

I could set the externals to point to a specific revision, but that seems a bit of a hassle, unless there is an automation (some nice shell command to make all externals point to the latest revision at that moment?)
I could localize the externals, if again there is some nice automation that would grab the current external and "localize" it, i.e. making it a permanent hard copy in the project.

Do such things exist with TortoiseSVN? Or am I corrupting the system somehow?

As far as I know TortoiseSVN doesn't provide such sophisticated functionality. You need to implement own scripts for checking these externals/changing them, i.e. what you've called automation.

Actually, we have the same inconveniences in our projects. We have a project tree (trunk - our working sources) with externals to tags (other teams working sources), they have own tags, and, moreover, we have a tags of our project tree of course. So, we have nested externals of 3, 4 and more orders. What we have done at this moment is the perl script (calls svn command line tool and process its result) which checks recursively whether all externals in our project tree tag are externals to tags or not (it is our own rule - in tags all externals must be to tags). The main point in this checking is that if at least one of externals points to trunk - the main idea behind our project tree would become pointless (based on the another important rule - never make changes in tags). As a rule it is a problematic to get that particular state of sources if these rules are violated (and as a result even inability to build application from these sources).

Summing up, I'd recommend developing own concepts, rules and use scripts for automation where it's possible.

You raise a very good point with the "externals should always be tags" policy. I might just do that.

MPelletier 2010-10-06 21:55:22

A small correction: externals in tags must be to tags; in working trunk it's usually appropriate to have externals to other trunks. This implies a certain procedure of tagging is needed: 1. project trunk goes to branch; 2. all externals to trunks is to be replaced with externals to tags; 3. after checking - branch goes to tag

Pmod 2010-10-07 06:40:47

I'm not disputing your company's policy, but at the same time I am trying to develop one for my own. Would it be so bad to have a project's trunk point to an external tag? When the external changes and is released, your project trunk can point to the new tag to say it is updated. Otherwise, you have a project trunk pointing to a potentially non-compatible external trunk... I'm just thinking "out loud", the debate is far from complete.

MPelletier 2010-10-07 13:43:01

I'm just trying to find the sanest solution. Making a release is becoming a lot of work. I gotta script some of the tedious stuff...

MPelletier 2010-10-07 14:31:28

You are right; and what you're saying made me think that there are two types of externals (one of the possible classifications): externals which you want to see stable (sources you're not responsible for or shared between teems) - these are externals to tags, basically, even in trunk; and the second type - externals which are used for aggregation of project tree from different locations - these are, basically, externals to trunks;

Pmod 2010-10-07 16:16:39

ansaurus

tags:

views:

answers:

How to manage historical externals in SVN

related questions