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
Received on Fri Mar 12 09:00:45 2004