Re: CVS Modules/ SVN Externals

Patrick,

Thanks for the response.

That does seem somewhat helpful for third party
libraries, but still quite limited.

I have ( er, will have ) the same issue with my
developers and I regarding tunnelling through ssh.
seems to me that you should be able to specify an
externals property like so:

libs/bar /trunk/libs/thirdparty/bar

and it would use the same connection info that you are
using to get the current project.

---
The problem with the way externals work now is that if
your current project ( the one that has this externals
property set on i
t ) is actually in a branch, and you commit something
in there that should stay on the branch till you
merge, you're actually c
ommiting to the trunk and possibly breaking things.
this possible breakage may seem like a reasonable
trade off for third party apps ( "If you need to make
a change to a third party library that's set as an
external property, then checkout that library on it's
own, and test there, then commit to trunk" ), but it's
not acceptable for checkouts that bring together
common code from 10 other directories.  ideally it
would use a relative path from where you checked it
out ( so if you checked out /trunk/someapp , and the
externals was   common/app_win  common/app_win, then
it would checkout /trunk/someapp.  likewise, if you
checked out /branches/wildnewfeature/someapp, it would
checkout /branches/wildnewfeature/common/app_win.  
for this to work, you'd have to make it so when you
commit any copies to a branch or tag dir, it would
also copy all the externals too ( effectivly
branching/tagging the common components specified in
the externals property ).    that sounds like a
nightmare.
Am I asking for too much?
-corris
--- Patrick Sunter <patrick@vpac.org> wrote:
> Hi Corris,
> 
> I'm too have found my only gripe with svn so far is
> the limited abilities of 
> svn:externals.
> 
>  > Ideally we'd like to tag a "module" which
>  > would tag the source, and all the shared
> components.
> 
> in a previous mailing list post, someone pointed out
> that there's an optional in 
> the svn:externals definition to add a revision
> number to the URL eg:
> foo/bar -r 1234 http://example.com/repos/zag
> (this is documented in "svn help propset", but not
> in the Book, strangely)
> 
> So one approach would be:
> 1. Create your tag by svn copying the project to a
> tag URL.
> 2. Check out the tag URL, and modify each
> svn:externals definition to point to 
> the correct revision (or tag) of the shared code
> they import.
> 
> A bit cumbersome, but at least it means you have
> full control over which 
> tag/revision you use of each imported bit of code.
> 
> I don't think the svn:externals is something the
> developers have put much effort 
> into yet - I pointed out that they don't really work
> if you're using port 
> forwarding through ssh the other day, and got no
> response.
> 
> cheers, Patrick.
> 
> -- 
> Patrick Sunter
> --------------
> Visitor in Geophysics
> Center for Advanced Computing Research
> Mail Code : 158-79
> California Institute Of Technology,
> Pasadena, CA 91125, USA.
> Ph : +1 (1) 626 395 2565
> Fax : +1 (1) 626 584 5917
> E-Mail : patrick@cacr.caltech.edu
> --------------
> Project Coordinator & Software Engineer
> Victorian Partnership for Advanced Computing
> E-Mail: patrick@vpac.org
__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org