Christian Daudt wrote:
>This is exactly the limitation of the current implementation - there are cases
>in which you need one functionality and cases in which you need the other.
>You'd need rules to specify what svn should do.
>
> I see 2 streams here:
> - because svn:externals is bad, remove it altogether.
> - because svn:externals is bad, improve it right away.
>
> how about: "leave the bad svn:externals alone, and create an improved version
>down the road (post 1.0)".
>
How do you make something 'better' when the functionality is ambiguous?
You will never get people to agree on always going with one mechanism or
the other - automatically creating a tag directory or updating the
externals tag to reference a revision vs. staying on the existing
head/branch/tag. What happens if the external project has more external
projects of its own? Same thing? If the external project is 'truely'
external (not on the local server), is the branch/tag created on the
remote server, or is the code migrated locally? Should login credentials
migrate to an external directory on the same server? separate server?
I vote for a third option - svn:externals should be designed to be as
simple to implement and with as few edge cases as possible. It should be
stupid simple. If people want more, they either use an external project
management system (which doesn't quite exist yet), or emulate it via
checkout/build scripts.
-David Waite
P.S. my answers to the above:
an external-ized reference should never be updated by subversion itself
login credentials should not migrate to external-ized directories, local
or remote. Of course, if there is a password in the cache, use it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 24 08:59:29 2003