On Wednesday 23 July 2003 23:58, David Waite wrote:
> 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?
What is ambiguous is what people would like to do with it, not what it can do
today. The current functionality is quite clear, only very limited.
Maybe I didn't express myself well on the sentence above, I meant "... and
create a new command to properly handle this improved functionality that
everyone would like to see from svn:externals down the road".
> 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?
>
People don't have to agree - if the functionality is flexible enough the
people's different needs (and projects' different needs) can be handled. How
different would this be from the fact that svn doesn't impose any mechanisms
on branching/tagging, leaving everything up to users? The fact that a "cp"
can be either a branch, a release tag or a plain old copy and it doesn't
matter to svn - only to the semantics I assign to my repository hierarchy -
is extremely powerful. I'm hoping for a similarly powerful way to manage the
connection between different parts of the repository (and possibly different
repositories).
> 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.
>
how is this different from the current svn:externals ?
> -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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 24 19:35:21 2003