Norbert Unterberg <nunterberg@gmail.com> writes:
> 2005/6/28, John Peacock <jpeacock@rowman.com>:
> > Ben Collins-Sussman wrote:
> > > Hm, this might be a bug. What you're saying is that 'svn up -r X'
> > > updates the working copy to revision X, but updates the externals to HEAD?
> >
> > What other choice would you have Subversion make? Externals can point
> > at a completely different repository, so there it is highly likely that
> > the same rev number has no correlation there.
>
> This issue is coming up again and again. Are there any plans about a
> new property that is designed for this kind of requests, like
> "svn:internals" or a smarter "svn:externals" property that would
> accepts relative paths inside the same repository (so they survive
> branching and tagging)?
There is an open issue (#1336) about svn:externals accepting relative
URLs, yes. Great idea, in my opinion.
But that is entirely independent from the question of how revisions
should behave. Even if a relative URL is used, there is no reason to
assume that the revision of the external working copy should
implicitly track the revision of the "main" working copy. That said,
I would not strongly oppose adding a new "EXT" revision keyword (like
"HEAD", "PREV", ...) which means, "Use the revision of the directory
whose svn:externals property is controlling this working copy as an
external" (and of course, is only valid when used in externals
definitions. If folks use -rEXT with externals that aren't in the
same repository, they'll just (likely) get completely broken behavior,
of course.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jul 7 16:58:37 2005