svn:externals to another svn:externals issue

[Andrew <on...@gmail.com>]

Hello all!

I've got an issue with a repo that I manage regarding svn:externals
and have been unable to find any information regarding it (apologies
if the issue has already been brought up and I didn't find it.)

So I've got a pair of projects, we'll call them /tools and /libs.
Under each I'm using ./tags/v1.0 ./tags/v2.0 as well as an
svn:externals of ./tags/latest which points to the most recent tagged
version.  This all works fine.  What I'd like to do and seem to be
unable is to use svn:externals to point from /tools/tags/v2.0/libs to
/libs/tags/latest, as that directory only exists as a property of it's
parent.  I'd like to use this so that I don't have to worry about
updating the libs path for my tools every time I release a new
version.

Does anyone have any ideas on how I might be able to accomplish this
or a more effective way of managing this code?

Thanks!

-- 
Andrew
http://blog.psych0tik.net

Re: svn:externals to another svn:externals issue

[Daniel Shahaf <da...@elego.de>]

Stephen Butler wrote on Wed, Jan 18, 2012 at 08:56:34 +0100:
> One idea is to
> 
>   svn rm ^/libs/tags/latest
>   svn cp ^/libs/tags/1.1 ^/libs/tags/latest

ITYM

    svnmucc rm ^/libs/tags/latest cp HEAD ^/libs/tags/1.1 ^/libs/tags/latest

Re: svn:externals to another svn:externals issue

[Stephen Butler <sb...@elego.de>]

On Jan 17, 2012, at 17:33 , Andrew wrote:

> Hello all!
> 
> I've got an issue with a repo that I manage regarding svn:externals
> and have been unable to find any information regarding it (apologies
> if the issue has already been brought up and I didn't find it.)
> 
> So I've got a pair of projects, we'll call them /tools and /libs.
> Under each I'm using ./tags/v1.0 ./tags/v2.0 as well as an
> svn:externals of ./tags/latest which points to the most recent tagged
> version.  

Subversion tags are URLs in a repository.  The svn:externals values 
are stored, but not interpreted, in the repository.  

> This all works fine.  What I'd like to do and seem to be
> unable is to use svn:externals to point from /tools/tags/v2.0/libs to
> /libs/tags/latest, as that directory only exists as a property of it's
> parent.  I'd like to use this so that I don't have to worry about
> updating the libs path for my tools every time I release a new
> version.
> 
> Does anyone have any ideas on how I might be able to accomplish this
> or a more effective way of managing this code?

One idea is to

  svn rm ^/libs/tags/latest
  svn cp ^/libs/tags/1.1 ^/libs/tags/latest

every time you create a new tag, so that the .../latest URL is a copy
of the most recent tag.  Teams accustomed to "promotion levels"
(i.e., coming from a version control system that includes build and
release management) often use this kind of scheme after switching 
to Subversion.

But the actual content of .../latest is obscured by the generic name.
You need to run 'svn log' to find out what's actually there.

I'd prefer to use unique tag URLs in svn:externals, with peg revisions
of course.  When tagging a new releases, instead of silently swapping
a .../latest URL, I'd announce it via a bug-tracker or continuous 
integration system.  Or by email or just shouting across the room.  

Steve
--
Stephen Butler | Consultant
elego Software Solutions GmbH
Gustav-Meyer-Allee 25, 13355 Berlin, Germany
tel: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elego.de
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719

Re: svn:externals to another svn:externals issue

[Ryan Schmidt <su...@ryandesign.com>]

On Jan 17, 2012, at 10:33, Andrew wrote:

> So I've got a pair of projects, we'll call them /tools and /libs.
> Under each I'm using ./tags/v1.0 ./tags/v2.0 as well as an
> svn:externals of ./tags/latest which points to the most recent tagged
> version.  This all works fine.  What I'd like to do and seem to be
> unable is to use svn:externals to point from /tools/tags/v2.0/libs to
> /libs/tags/latest, as that directory only exists as a property of it's
> parent.  I'd like to use this so that I don't have to worry about
> updating the libs path for my tools every time I release a new
> version.
> 
> Does anyone have any ideas on how I might be able to accomplish this
> or a more effective way of managing this code?

My advice is don't. Instead, continue doing what you've presumably been doing: update the external to the specific version that your code works with. How can you guarantee today that you won't next month modify the library in a way that is not backwards-compatible?