You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Patrick Sunter <pa...@vpac.org> on 2004/03/10 03:30:43 UTC
Re: CVS Modules/ SVN Externals
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS Modules/ SVN Externals
Posted by Patrick Sunter <pa...@vpac.org>.
Corris Randall wrote:
>
> Patrick,
>
<snip>
> 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.
>
Yes, that seems like a simple solution:- no protocol specified at the start
means to use the current one. Wouldn't be too hard to implement methinks?
> ---
>
> 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.
Agreed.
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
You mean sounds like a nightmare to have to manage manually? Yes, why leave room
for human forgetfulness, when you could automate it (and with svn's cheap copy
it wouldn't chew through heaps of disk space anyway).
I think the crux of the issue is this:- svn:externals is a great way of
automaticaly including code from a conceptually different project, be it coded
in-house, or somewhere else entirely. But it doesn't capture the essentials of
what cvs modules could:- being able to re-use small modules of common code
throughout one or more projects. The branching issue you've pointed out shows
that this functionality needs to be thought out carefuly too.
cheers, Pat.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS Modules/ SVN Externals
Posted by Patrick Sunter <pa...@vpac.org>.
Corris Randall wrote:
>
> Patrick,
>
<snip>
> 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.
>
Yes, that seems like a simple solution:- no protocol specified at the start
means to use the current one. Wouldn't be too hard to implement methinks?
> ---
>
> 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.
Agreed.
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
You mean sounds like a nightmare to have to manage manually? Yes, why leave room
for human forgetfulness, when you could automate it (and with svn's cheap copy
it wouldn't chew through heaps of disk space anyway).
I think the crux of the issue is this:- svn:externals is a great way of
automaticaly including code from a conceptually different project, be it coded
in-house, or somewhere else entirely. But it doesn't capture the essentials of
what cvs modules could:- being able to re-use small modules of common code
throughout one or more projects. The branching issue you've pointed out shows
that this functionality needs to be thought out carefuly too.
cheers, Pat.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: CVS Modules/ SVN Externals
Posted by Corris Randall <co...@yahoo.com>.
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 <pa...@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: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS Modules/ SVN Externals
Posted by Corris Randall <co...@yahoo.com>.
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 <pa...@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